Re: Bootstrapping into git, commit gripes at me
Dear diary, on Tue, Jul 12, 2005 at 06:48:50PM CEST, I got a letter where Linus Torvalds <[EMAIL PROTECTED]> told me that... > Then "cg-seek" and "cg-unseek" would continue to work, but the core git > layer would never be confused because they're really using normal > branches? That makes sense, I just did exactly that. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bootstrapping into git, commit gripes at me
Petr Baudis <[EMAIL PROTECTED]> writes: > After some thought, I like Linus' approach more now, having head-name > only when it's really necessary. I agree 100%. That makes much more sense. The message from Linus reminded me that the way he tackles a problem is (as always) simpler, consistent and more elegant than mine. I have been practicing thinking things through more than three times before I open my mouth, but still... - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bootstrapping into git, commit gripes at me
Dear diary, on Tue, Jul 12, 2005 at 11:07:43AM CEST, I got a letter where Junio C Hamano <[EMAIL PROTECTED]> told me that... > If you block certain operations while you have seeked to non-top > anyway, wouldn't it be cleaner to have .git/seeked-to that > records the commit ID you are at, which at the same time > indicates that you are in a special situation, and not touching > HEAD at all? Then .git/HEAD will always have that line of > development information. > > Well, that was half tongue-in-cheek suggestion; I have a feeling > that you may feel it is a bit too late to change this kind of > thing easily. The thing is, _everything_ assumes .git/HEAD is the current commit checked out in the index. All the Cogito (that wouldn't be hard to change at all), all the other Porcelains, the core GIT tools. So changing that would be difficult and it's much easier this way. > But if we are going to agree on using .git/head-name, I'd rather > see it exist all times, so that cat "$GIT_DIR/head-name" would > always tell us which branch we are working in. After some thought, I like Linus' approach more now, having head-name only when it's really necessary. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bootstrapping into git, commit gripes at me
On Mon, 11 Jul 2005, Junio C Hamano wrote: > Linus Torvalds <[EMAIL PROTECTED]> writes: > > > But what about the branch name? Should we just ask the user? Together with > > a flag, like > > > > git checkout -b new-branch v2.6.12 > > > > for somebody who wants to specify the branch name? Or should we pick a > > random name and add a helper function to rename a branch later? > > > > Opinions? > > How about treating "master" a temporary thing --- "whatever I > happen to be working on right now"? That conflicts with my usage, where I have a single repository for all of my working directories, with .git/refs and .git/objects being symlinks to it, but .git/HEAD being different for each branch. The stuff in objects/ and refs/ really shouldn't depend on what you're currently doing for this reason. My way of thinking of "master" is that it's a real branch, which is for all of the situations where you aren't using a specially-designated branch. For many people, they only do stuff that's not designated specially; Jeff only does stuff that is designated specially. But if you do both, you'll want master to be left alone while you work on the side branch. -Daniel *This .sig left intentionally blank* - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bootstrapping into git, commit gripes at me
On Tue, 12 Jul 2005, Petr Baudis wrote: > > Could we please have the branch name written to .git/head-name in case > we switch the branch? I wouldn't mind per se, but on the other hand I really _hate_ having "parallel" information that can get out of sync. If you have two places holding the same information, they had better match. And this is something that sounds like it could very easily start to not match, and then we're screwed. So I'd _much_ rather see instead: - .git/head-name is a cogito-specific thing that is only active while cogito is _seeking_. So then "cg-unseek" ends up being pretty much equivalent to [ -e .git/head-name ] || die "You weren't seeking" git checkout $(cat .git/head-name) rm .git/head-name This way "head-name" is really never even supposed to be "in sync" with .git/HEAD, and there are no synchronization issues. - in order for a "git checkout" to not get confused and possibly throwing a cogito temporary head away (and so that git-fsck-cache is happy during a seek), would it be possible to make "seek" use a real temporary branch instead? Ie, "cg-seek" would be something like [ -e .git/head-name ] && die "You are already seeking" readlink .git/HEAD > .git/head-name echo $seekpoint > .git/refs/heads/cg-seek-point git checkout -f cg-seek-point or similar? Then "cg-seek" and "cg-unseek" would continue to work, but the core git layer would never be confused because they're really using normal branches? Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bootstrapping into git, commit gripes at me
Hi, Junio C Hamano wrote:
> Having said that, I do like the concept of keeping track of
> "which development line are we on, and what's most recent in
> it". The way I read your description of cg-seek, you currently
> have that information is either in .git/head-name and
> .git/refs/heads/ pair (when .git/head-name exists),
> or .git/HEAD.
Personally, I'd rather have as few invariants as possible, so that various
Porcelains can agree on semantics.
What I would expect from a sane .git tree is that
* .git/HEAD contains the commit that is currently checked out.
* If HEAD is not a symlink, then switching to a branch HEAD is not a part
of should emit a warning.
("fsck to find the dangling commits" is not an answer ;-)
Ideas like
* remember the branch to un-seek back to
or
* treat HEAD as read-only when there's a seek active
seem to be optional / Porcelain-specific.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
"We'll strategically withdraw to previously prepared position."
"Who prepared them?"
"we'll prepare them when we get there."
-- Terry Pratchett (Reaper Man)
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bootstrapping into git, commit gripes at me
I do want to see various Porcelains to agree on how to store state information in $GIT_DIR for doing common operations, when they are conceptually compatible. The way they handle branches may fall into that category. With the barebone GIT Porcelain, "seek" like operation may simply be done by creating another branch or tag and jumping to it, so there may not be the concept of "seek", in which case they may not be compatible after all. Having said that, I do like the concept of keeping track of "which development line are we on, and what's most recent in it". The way I read your description of cg-seek, you currently have that information is either in .git/head-name and .git/refs/heads/ pair (when .git/head-name exists), or .git/HEAD. If you block certain operations while you have seeked to non-top anyway, wouldn't it be cleaner to have .git/seeked-to that records the commit ID you are at, which at the same time indicates that you are in a special situation, and not touching HEAD at all? Then .git/HEAD will always have that line of development information. Well, that was half tongue-in-cheek suggestion; I have a feeling that you may feel it is a bit too late to change this kind of thing easily. But if we are going to agree on using .git/head-name, I'd rather see it exist all times, so that cat "$GIT_DIR/head-name" would always tell us which branch we are working in. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bootstrapping into git, commit gripes at me
Dear diary, on Tue, Jul 12, 2005 at 06:34:33AM CEST, I got a letter where Linus Torvalds <[EMAIL PROTECTED]> told me that... > On Mon, 11 Jul 2005, Linus Torvalds wrote: > > > > Of course, if you want to create a new branch "my-branch" and _not_ > > check it out, you could have done so with just > > > > git-rev-parse v2.6.12^0 > .git/refs/heads/my-branch > > > > which I think I will codify as "git branch". > > And now we have that "git branch". It's a trivial one-liner, except with > the setup and error checking it's actually more like six lines. Could we please have the branch name written to .git/head-name in case we switch the branch? The reason is that .git/HEAD may not be always a symlink. Specifically, I do this - there's a command cg-seek, which will seek your working tree to a given commit, while staying on the branch (committing and some other operations are blocked). In that case, I remove .git/HEAD and replace it with ID of the commit I'm seeked at, and when I'm "unseeking" back to the top, I replace it with the symlink again. With some heuristics, I could create .git/head-name at the time of seek and hope, but I think it'd be cleaner to just always set it (except when we are on the master branch), if you agree. Note that even though Cogito won't let you create/change a local branch yet, it will understand .git/head-name and hopefully behave properly (although it's totally untested, of course). -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ be careful, some twit might quote you out of context.. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bootstrapping into git, commit gripes at me
On Mon, Jul 11, 2005 at 09:59:25PM -0700, Linus Torvalds wrote: > > > On Mon, 11 Jul 2005, Marc Singer wrote: > > > > Does it make sense to think about this branch as an flow of commits? > > Or is it just a starting point for a line of development? > > It's really a flow of commits. Nothing will ever really remember what the > starting point was at some later date if you have done commits, and the > branch will always follow the _head_ of development on that branch. That's the important detail. As an aside, we (a vary large set of developers) have been using SCM tools for how-many-freakin-years and only now am I seeing something sane. Cheers. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bootstrapping into git, commit gripes at me
On Mon, 11 Jul 2005, Marc Singer wrote: > > Does it make sense to think about this branch as an flow of commits? > Or is it just a starting point for a line of development? It's really a flow of commits. Nothing will ever really remember what the starting point was at some later date if you have done commits, and the branch will always follow the _head_ of development on that branch. So if you need to remember the starting point as a _static_ entity, you need to create a tag pointing to that place. You can do that at any point, very much including after you've already done development (but before you forget what to tag ;) > If I make a branch, check it out, commit changes to it, and then clobber > the working directory, can I later resume that branch of development > without creating a new branch? Absolutely. You can create a branch, commit to it, switch to another branch, commit to that one, switch back to the branch you created, and just go on. A branch will always follow the development. > Do I need to set a tag to mark the last commit on that branch? No, but as mentioned, _if_ you care about remembering where you _started_ the branch, you may want to tag that. Of course, most of the time you really really don't care. It will be largely obvious from the global commit history, which you can trivially visualize with "gitk --all". You'll see where your branch "split off" the main branch, and the only case where that is ambiguous is if you started your branch at the tip of another branch, and no other development has gone on in that other branch - then you don't see a "fork". Of course, the other reason you usually don't care where you started is that you simply don't care. When you use CVS, you usually need to know where the branch was started (and each point it was merged at) just so that you can sanely merge it by doing diffs etc. With git, since we have all the proper history, that's not necessary at all. So I _suspect_ that most of the time when you create a branch, you don't need to tag where you started. Others will see what is your development simply by virtue of it being in your tree and not in other peoples tree, whether you created a branch for that or not ;) Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bootstrapping into git, commit gripes at me
On Mon, Jul 11, 2005 at 09:34:33PM -0700, Linus Torvalds wrote: > > > On Mon, 11 Jul 2005, Linus Torvalds wrote: > > > > Of course, if you want to create a new branch "my-branch" and _not_ > > check it out, you could have done so with just > > > > git-rev-parse v2.6.12^0 > .git/refs/heads/my-branch > > > > which I think I will codify as "git branch". > > And now we have that "git branch". It's a trivial one-liner, except with > the setup and error checking it's actually more like six lines. Does it make sense to think about this branch as an flow of commits? Or is it just a starting point for a line of development? If I make a branch, check it out, commit changes to it, and then clobber the working directory, can I later resume that branch of development without creating a new branch? Do I need to set a tag to mark the last commit on that branch? - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bootstrapping into git, commit gripes at me
On Mon, 11 Jul 2005, Linus Torvalds wrote: > > Of course, if you want to create a new branch "my-branch" and _not_ > check it out, you could have done so with just > > git-rev-parse v2.6.12^0 > .git/refs/heads/my-branch > > which I think I will codify as "git branch". And now we have that "git branch". It's a trivial one-liner, except with the setup and error checking it's actually more like six lines. Linus --- commit 37f1a519f2ea0ce912ccd7c623aea992147c3900 Author: Linus Torvalds <[EMAIL PROTECTED]> Date: Mon Jul 11 21:30:23 2005 -0700 Add "git branch" script You can use it as git branch [start-point] and it creates a new branch of name . If a starting point is specified, that will be where the branch is created, otherwise it will be created at the current HEAD. The sequence git branch xyz abc git checkout xyz can also be written as git checkout -b xyz abc as per the previous commit. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bootstrapping into git, commit gripes at me
On Mon, Jul 11, 2005 at 08:41:43PM -0700, Junio C Hamano wrote: > When I start working on something I often do not know what the > thing I am going to work on ends up to be. So I would start > from v2.6.12 tag, do random hacking, and when I got into a > reasonable shape, I would say ``Ok, this is worth saving. Let's > name it "foobar" branch and continue.'' And I would probably > switch to some other subproject when an urgent bugfix comes in, > and I would not want to lose my "master" _then_. So (the > "branch" one has been revised): Isn't that what a tag is for? o Make a sandbox o Commit cool changes o Tag the last commit object o Throw sandbox away. o Push changes or generate patch based on the tag The change is that we can create a sandbox by giving it a starting point, a tag. If we decide we want to keep working on this branch, all we'd have to do is go back to that tag, although I admit it may seem sloppy to have to create a new branch from a tag'd commit that we originally part of a branch. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bootstrapping into git, commit gripes at me
On Mon, 11 Jul 2005, Junio C Hamano wrote:
>
> I do not quite follow your objections. I do not think I am
> forcing anybody to name an old thing.
Sure you are. You're forcing them to make a choice, where both choices
are bad. Either:
- name an old thing (that you may not even have worked on - "master" from
a newly cloned repo)
- throw the old master state away ("--force")
Either choice is bad.
Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bootstrapping into git, commit gripes at me
On Mon, 11 Jul 2005, Linus Torvalds wrote: > On Mon, 11 Jul 2005, Marc Singer wrote: > > > > From my POV, what I want is a branch with the tag v2.6.12 as the basis > > of the branch. I'm guessing that -b means "make me a branch and call > > it this". > > Yup. That would be the interface. > > > # git checkout -b BRANCH_NAME [TAG] > > > > If the TAG is omitted, the branch is made from the current HEAD or > > some other reasonable point defined by the current working directory. > > That would be the most natural thing that would fall out of this kind of > interface. Ok, done. Now, if you try to do git checkout v2.6.12 git will complain with git checkout: you need to specify a new branch name and some day (when I can get my act together and have man-pages that work), there would even be documentation for the "-b" flag to specify the branch name. And indeed, if you only specify the branch name, it will just create it and switch to it from the current HEAD. So while there are no docs, the checkin comment hopefully says it all: Linus --- commit 91dcdfd3b5331d955cfb60edf8930f1b5c142905 Author: Linus Torvalds <[EMAIL PROTECTED]> Date: Mon Jul 11 20:44:20 2005 -0700 Make "git checkout" create new branches on demand In particular, if we check out something that isn't an old branch, it now requires a new branch-name to check the thing out into. So, for example: git checkout -b my-branch v2.6.12 will create the new branch "my-branch", and start it at v2.6.12, while git checkout master will just switch back to the master branch. Of course, if you want to create a new branch "my-branch" and _not_ check it out, you could have done so with just git-rev-parse v2.6.12^0 > .git/refs/heads/my-branch which I think I will codify as "git branch". - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bootstrapping into git, commit gripes at me
Linus Torvalds <[EMAIL PROTECTED]> writes: > So at least to me it makes much more sense to say "ok, I'll start > something new, and call it xyzzy", than "ok, I'll start something new, and > I'll save the old under 'old'". > > The "old" thing might not even be anything you worked on (it might be > something you just cloned from somebody else), so you giving it a name > isn't very logical. In contrast, you're clearly doing something active > with the new thing, so naming _that_ makes sense. What I had mind was ``If you do not care about the current "master", just say "checkout --force"''. When I start working on something I often do not know what the thing I am going to work on ends up to be. So I would start from v2.6.12 tag, do random hacking, and when I got into a reasonable shape, I would say ``Ok, this is worth saving. Let's name it "foobar" branch and continue.'' And I would probably switch to some other subproject when an urgent bugfix comes in, and I would not want to lose my "master" _then_. So (the "branch" one has been revised): checkout [--force] In addition to reading the tree and updating the work tree, stores "^0" in .git/refs/heads/master. However, if the current "master" is not something that matches a refs/*/*, then the user will be losing the trail between "master" before checkout and what is recorded in refs/, so the user needs to allow me explicitly to do it. branch Save the current "master" to branch-name. If the user makes a mistake and tries to store the "master" head into a wrong branch, that would lose development trail of the branch being overwritten, so if the named branch exists and "master" is not a descendent of it, the user needs to explicitly tell me that it is OK to do so. I do not quite follow your objections. I do not think I am forcing anybody to name an old thing. Do you mean that "I've been working on A and now I want to switch to B; so I'll save the current state in A and switch to B" is too redundant, and I should just let the user say "I've been working on something I do not care to remember, now I want to switch to B, so just take me to B and you should remember where I was and save it to A automatically"? That sort of makes sense to me. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bootstrapping into git, commit gripes at me
On Mon, 11 Jul 2005, Junio C Hamano wrote: > > > Opinions? > > How about treating "master" a temporary thing --- "whatever I > happen to be working on right now"? I'd not mind with this in theory, but it has the fundamental problem that we can end up losing sight of commits we have, and then have no way to reach them. Which is ok per se - sometimes you simply don't care about them, and I occasionally drop some commits on purpose when I've done something I decide to undo and then do a "git prune" to get rid of the objects. But I don't want this to happen _easily_. Your examples aren't actually very interesting: > - git branch;# copies master to branch-name; >if branch-name exists in refs/heads, > warn and refuse. Override >with --force flag. > > - git checkout ;# copies branch-name to master; but > if master does not match any > of the other refs/heads/, warn > and refuse. Override with > --force flag. because those two examples end up avoiding the _real_ issue, which is the git checkout v2.6.12 case, which is exactly the case that would need a "--force" flag, since master is what you're working on before. And --force would drop that information. So I want something that naturally works with this (very reasonable) way of working, and does _not_ force people to drop information. In your world, you'd have to first save the old master with git branch work-branch and then you could do git checkout v2.6.12 to start on "master" anew. That's fair, but it's conceptually very wrong: it rquires you to name the _old_ thing, which to me just sounds very confusing indeed. You don't care about the old thing, it's the _new_ thing you care about. So at least to me it makes much more sense to say "ok, I'll start something new, and call it xyzzy", than "ok, I'll start something new, and I'll save the old under 'old'". The "old" thing might not even be anything you worked on (it might be something you just cloned from somebody else), so you giving it a name isn't very logical. In contrast, you're clearly doing something active with the new thing, so naming _that_ makes sense. Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bootstrapping into git, commit gripes at me
On Mon, 11 Jul 2005, Marc Singer wrote: > > From my POV, what I want is a branch with the tag v2.6.12 as the basis > of the branch. I'm guessing that -b means "make me a branch and call > it this". Yup. That would be the interface. > # git checkout -b BRANCH_NAME [TAG] > > If the TAG is omitted, the branch is made from the current HEAD or > some other reasonable point defined by the current working directory. That would be the most natural thing that would fall out of this kind of interface. > Are uncommitted changes present in the working directory maintained? > Discarded? I wont't care since I'll never be doing that. At least, > not on purpose. They'd be maintained. If they clash with the target being checked out (ie the checked-out tag would have changes to those files) it would error out with a "I can't do that, Dave". Unless you give the "-f" flag, in which case they're all thrown out, and "git checkout" will force the new state and throw away any old state entirely. Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bootstrapping into git, commit gripes at me
Linus Torvalds <[EMAIL PROTECTED]> writes: > But what about the branch name? Should we just ask the user? Together with > a flag, like > > git checkout -b new-branch v2.6.12 > > for somebody who wants to specify the branch name? Or should we pick a > random name and add a helper function to rename a branch later? > > Opinions? How about treating "master" a temporary thing --- "whatever I happen to be working on right now"? - git branch;# copies master to branch-name; if branch-name exists in refs/heads, warn and refuse. Override with --force flag. - git checkout ;# copies branch-name to master; but if master does not match any of the other refs/heads/, warn and refuse. Override with --force flag. Yes I realize that you have to be careful when to push to your public repository if you take this route, but this is only relevant to people like Jeff with multiple heads, and I think he publicly stated that his "refs/heads/master" aka .git/HEAD does not mean much and what matters are his branch heads. People who do not use multiple branches but just checks out various tags, the above would be reasonably convenient. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bootstrapping into git, commit gripes at me
On Mon, Jul 11, 2005 at 06:43:23PM -0700, Linus Torvalds wrote: > > > On Mon, 11 Jul 2005, Linus Torvalds wrote: > > > > No, git-checkout-script _shouldn't_ have done that. It will do the > > read-tree on the tag (which will do the right thing), but it won't change > > the HEAD itself. > > In preparation of actually updating the HEAD, I just made "git checkout" > verify that it only checks out a commit, not a tree tag or something like > that. Too late for Marc, but next time around a "git checkout v2.6.11" :-) > will result in > > [EMAIL PROTECTED] linux]$ git checkout v2.6.11 > error: Object 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c is a tree, not a > commit > Needed a single revision > > On the other hand, creating a new branch might be a but surprising to > people: "But I just wanted to check it out". But as far as I can see, it's > the only safe thing to do, and it has the advantage that you can then go > back to the old state with a simple "git checkout master". > > But what about the branch name? Should we just ask the user? Together with > a flag, like > > git checkout -b new-branch v2.6.12 > > for somebody who wants to specify the branch name? Or should we pick a > random name and add a helper function to rename a branch later? > > Opinions? >From my POV, what I want is a branch with the tag v2.6.12 as the basis of the branch. I'm guessing that -b means "make me a branch and call it this". # git checkout -b BRANCH_NAME [TAG] If the TAG is omitted, the branch is made from the current HEAD or some other reasonable point defined by the current working directory. Are uncommitted changes present in the working directory maintained? Discarded? I wont't care since I'll never be doing that. At least, not on purpose. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bootstrapping into git, commit gripes at me
On Mon, 11 Jul 2005, Linus Torvalds wrote: > > No, git-checkout-script _shouldn't_ have done that. It will do the > read-tree on the tag (which will do the right thing), but it won't change > the HEAD itself. In preparation of actually updating the HEAD, I just made "git checkout" verify that it only checks out a commit, not a tree tag or something like that. Too late for Marc, but next time around a "git checkout v2.6.11" will result in [EMAIL PROTECTED] linux]$ git checkout v2.6.11 error: Object 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c is a tree, not a commit Needed a single revision That's not exactly _obvious_ either, but hey, it's at least a half-way readable and understandable error, and it's obviously correct to somebody who knows how git works. That still leaves the question about what to do when you do git checkout v2.6.12 which _is_ a valid operation. Right now it will "check out" that tag, in the sense that it will make the working tree correspond to v2.6.12, but it won't actually touch HEAD at all. The question is, what _should_ it do to head? Should it just reset HEAD to point to .git/refs/master, and then write the commit ID to it? That may actually sometimes be exactly what you want, and at least it will result in a consistent state (ie the next commit will have the right parent). On the other hand, it will blow away whatever the old "master" branch contained, and thus likely leave an unreachable commit. On the other hand, creating a new branch might be a but surprising to people: "But I just wanted to check it out". But as far as I can see, it's the only safe thing to do, and it has the advantage that you can then go back to the old state with a simple "git checkout master". But what about the branch name? Should we just ask the user? Together with a flag, like git checkout -b new-branch v2.6.12 for somebody who wants to specify the branch name? Or should we pick a random name and add a helper function to rename a branch later? Opinions? Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bootstrapping into git, commit gripes at me
On Mon, 11 Jul 2005, Junio C Hamano wrote: > > - we allow git-checkout-script with a tag; I think we store the tag >object without dereferencing in .git/HEAD; No, git-checkout-script _shouldn't_ have done that. It will do the read-tree on the tag (which will do the right thing), but it won't change the HEAD itself. But I think Marc has/had an older git-checkout-script. The original one didn't do branches at all, and indeed just blindly wrote its result into .git/HEAD. > My current preference is to keep .git/refs/heads tag free. At > least, I do not think we should ever write non commits to > .git/*_HEAD. And we don't. Not any more. However, right now we don't update .git/HEAD at _all_ unless we checked out a specific branch. Part of that is that we don't really know what we should change. Should we reset the current branch to that tag? Should we switch to the "master" branch, and switch _that_ to that tag? Should we create a totally new branch for just this thing? Creating a new branch ends up being the only _safe_ option, but what should we choose as the branch name? Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bootstrapping into git, commit gripes at me
On Mon, 11 Jul 2005, Marc Singer wrote: > > I picked 2.6.12 > > # git checkout -f v2.6.12 > > applied the patch and was greeted with an error about being unable to > commit telling me that I LONG_HEX_NUMBER is not a valid commit object. > Isn't 2.6.12 later than 2.6.12-rcX? Yes. However, that's not how "git checkout" ends up working, which is probably (almost certainly) a misfeature of git checkout. In particular, when you use a tag to checkout something, it will checkout the _state_ at that point (ie v2.6.12), but it won't have reset your HEAD to point to it. And your earlier adventures made your HEAD be something that isn't a commit (although I quite frankly don't know quite how you succeeded at that: "git checkout" should refuse to write a HEAD unless you check out a specific branch, and all branch pointers are proper commit points). Anyway, here's how you fix it right now, and I'll have to figure out how to make a nice interface: # # Reset the "master" branch to v2.6.12 # git-rev-list --max-count=1 v2.6.12 > .git/refs/heads/master # # Switch to the master branch # git checkout -f master which should get you to be at a known point (which is v2.6.12). Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bootstrapping into git, commit gripes at me
Junio C Hamano <[EMAIL PROTECTED]> writes:
>
> - git-commit-tree says check_valid("commit") and barfs.
>
> My current preference is to keep .git/refs/heads tag free. At
> least, I do not think we should ever write non commits to
> .git/*_HEAD.
>
> What do you think? An alternative would be to allow tags
> (recursively) pointing at a commit as a commit parent, but I do
> not think we would want to go that route.
Or, just dereferencing tags for commit parents in commit-tree
would be fine as well.
Dereference tags given as commit-tree -p parameters.
Marc Singer noticed that when he has a tag instead of a commit
in his .git/HEAD (this happens after git checkout -f ), git
commit barfs. This patch makes commit-tree dereference tags
like everybody else does.
Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
---
cd /opt/packrat/playpen/public/in-place/git/git.junio/
jit-diff
# - master: [PATCH] git-cvsimport-script: add "import only" option
# + (working tree)
diff --git a/commit-tree.c b/commit-tree.c
--- a/commit-tree.c
+++ b/commit-tree.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include "commit.h"
#define BLOCKING (1ul << 14)
@@ -133,10 +134,14 @@ int main(int argc, char **argv)
check_valid(tree_sha1, "tree");
for (i = 2; i < argc; i += 2) {
char *a, *b;
+ struct commit *commit;
a = argv[i]; b = argv[i+1];
if (!b || strcmp(a, "-p") || get_sha1(b, parent_sha1[parents]))
usage(commit_tree_usage);
- check_valid(parent_sha1[parents], "commit");
+ commit = lookup_commit_reference(parent_sha1[parents]);
+ if (!commit)
+ usage(commit_tree_usage);
+ memcpy(parent_sha1[parents], commit->object.sha1, 20);
if (new_parent(parents))
parents++;
}
Compilation finished at Mon Jul 11 16:12:36
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bootstrapping into git, commit gripes at me
Marc Singer <[EMAIL PROTECTED]> writes:
> I picked 2.6.12
>
> # git checkout -f v2.6.12
>
> applied the patch and was greeted with an error about being unable to
> commit telling me that I LONG_HEX_NUMBER is not a valid commit object.
> Isn't 2.6.12 later than 2.6.12-rcX?
Aha. Marc is not doing anything wrong --- he is doing as he is
told.
Linus, there is a bad interaction between tag objects and
commits right now. For example:
- we allow git-checkout-script with a tag; I think we store the tag
object without dereferencing in .git/HEAD;
- git-commit-tree says check_valid("commit") and barfs.
I think other things are covered already and the above two are
the only remaining major ones. The merge-base command dereferences tags
and produces a commit as its result. The rev-list command also
derefs tags, so log and whatchanged would work sensibly.
My current preference is to keep .git/refs/heads tag free. At
least, I do not think we should ever write non commits to
.git/*_HEAD.
What do you think? An alternative would be to allow tags
(recursively) pointing at a commit as a commit parent, but I do
not think we would want to go that route.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bootstrapping into git, commit gripes at me
On Fri, Jul 08, 2005 at 06:43:54PM -0700, Linus Torvalds wrote: > > > On Fri, 8 Jul 2005, Marc Singer wrote: > > > > In working through a usage example on my way to producing bonafide > > patches, I've found that commit is complaining. Here's what I've done. > > > > o Fetched and built cogito-0.12 > > o Fetched (rsync) Linus' tree > > o Created a working directory, linux-2.6 > > o linked .git in the working directory to the .git directory fetched > > from the net. > > o # git checkout -f v2.6.11 > > This won't work. > > v2.6.11 isn't a commit, it's a tree, and things will go downhill from > there. > > Can you base it on 2.6.12-rc2 or later? That's the earliest with some real > git history. I picked 2.6.12 # git checkout -f v2.6.12 applied the patch and was greeted with an error about being unable to commit telling me that I LONG_HEX_NUMBER is not a valid commit object. Isn't 2.6.12 later than 2.6.12-rcX? - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bootstrapping into git, commit gripes at me
Dear diary, on Sat, Jul 09, 2005 at 11:04:37PM CEST, I got a letter where Matthias Urlichs <[EMAIL PROTECTED]> told me that... > > o Is there a way to force git to apply and safe the rejects? > > Well, you can use "patch -p1 ..." directly, and manually add the files it > created to the object cache. Personally I wouldn't, if at all possible. Or you can do cg-patch, which should handle that for you properly as well. I think the "no fuzz" approach is hyper-paranoid. I deal with small or larger fuzz all the time when I'm reordering patches or applying them to a few hours younger version than they were based on. I think the restriction it imposes is overly draconian here and doesn't trust the developer to know what he is doing as much as it should. (And that's why cg-patch doesn't use git-apply. ;-) -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ be careful, some twit might quote you out of context.. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bootstrapping into git, commit gripes at me
Hi, Marc Singer wrote:
> Yet, patch does apply. [...]
> patching file drivers/ide/ide-io.c
> Hunk #1 succeeded at 96 with fuzz 2 (offset -33 lines).
git-apply cowardly (but sensibly) refuses to apply patches with fuzz
(i.e., ignoring some supplied context lines).
Fuzz indicates problems.
I'd suggest that you apply the patch to whatever version it is based on...
> o Is there a way to force git to apply and safe the rejects?
Well, you can use "patch -p1 ..." directly, and manually add the files it
created to the object cache. Personally I wouldn't, if at all possible.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
I couldn't remember things until I took that Sam Carnegie course.
-- Bill Peterson, former Houston Oiler football coach
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bootstrapping into git, commit gripes at me
On Fri, 8 Jul 2005, Marc Singer wrote: > > In working through a usage example on my way to producing bonafide > patches, I've found that commit is complaining. Here's what I've done. > > o Fetched and built cogito-0.12 > o Fetched (rsync) Linus' tree > o Created a working directory, linux-2.6 > o linked .git in the working directory to the .git directory fetched > from the net. > o # git checkout -f v2.6.11 This won't work. v2.6.11 isn't a commit, it's a tree, and things will go downhill from there. Can you base it on 2.6.12-rc2 or later? That's the earliest with some real git history. Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bootstrapping into git, commit gripes at me
> "MS" == Marc Singer <[EMAIL PROTECTED]> writes: MS> I gather that the approved solution is to have complete replicas of MS> the git master from Linus for each line of development. Either symlink .git/objects together, or GIT_OBJECT_DIRECTORY environment variable point at a shared repository, and just do not run git-prune-script and you will be fine. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bootstrapping into git, commit gripes at me
On Fri, Jul 08, 2005 at 05:17:08PM -0700, Junio C Hamano wrote: > > "MS" == Marc Singer <[EMAIL PROTECTED]> writes: > > MS> In working through a usage example on my way to producing bonafide > MS> patches, I've found that commit is complaining. Here's what I've done. > > MS> o Fetched and built cogito-0.12 > MS> o Fetched (rsync) Linus' tree > MS> o Created a working directory, linux-2.6 > MS> o linked .git in the working directory to the .git directory fetched > MS> from the net. > > This is slightly different from the BCP. A recommended way is: > > $ mkdir linux-2.6 > $ cd linux-2.6 > $ git-init-db > $ rsync linux-2.6.git/ from kernel.org into .git/ Does this preclude symlinking .git? I'd like to keep one .git which is mirrored from the net and allow for more than one working directory. > Although your commit problem does not have to do with this. > > MS> o # git checkout -f v2.6.11 > MS> o # cat ../old-patch-file | patch -p1 > > GITified Linux kernel repository starts at v2.6.12-rc2, so > from anything older you cannot create a commit off of it > (easily). Trouble is that 2.6.12 breaks some things and I need to continue to build patches from 2.6.11 for the time being. Once I get familiar, I'll patch the tree to build properly for my targets with later revisions. > MS> Then, according to Jeff's instructions, I have to perform > MS> get-update-cache with the name of each file I changed. Is that really > MS> the way? > > MS> o # git-update-cache LIST_OF_CHANGED_FILES > > That is correct. Also remember to say: > > git-update-cache --add LIST_OF_ADDED_FILES > git-update-cache --remove LIST_OF_REMOVED_FILES His text is a little overly-brief on this, but I got the gist. > Notice the use of git-apply --index instead of patch -p1 in the > above example? If you use git-apply --index, you do not have to > do the above steps yourself. Notice it...where? I gather that git-apply is a better way to apply patches? > MS>fatal: 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c is not a valid > 'commit' object > > That is a tag to the v2.6.11 tree, which is not a valid commit, > so you cannot make a commit off of it. So what does this mean? Can I only produce commits from the master? Is this a peculiarity of the v2.6.11 tag? > Linus, I think git-checkout-script should not store a tag to non > commit in HEAD. If that did not happen, and if the repo was > created without ref/heads/master (the usual case), then he > _could_ have done something like this: > > $ git checkout -f v2.6.11 ;# fixed one > warning: v2.6.11 is not a commit -- not updating your HEAD > $ git commit ;# to have his own baseline at v2.6.11 > $ git-apply --index --stat --summary --apply <../old-patch-file > $ : do the usual tests > $ git commit ;# create a commit based on the baseline v2.6.11 That sounds like what I'm looking for. Can I do this by hand somehow? As an ARM developer, I need to be able to cleanly track kernel development revisions and produce patches that are easy to merge. The cycle is something like this: o Update kernel tree. o Fix the build. o Produce a patch to send upstream. o Apply work-in-progress patches o Fix the build. o Publish new patches against updated kernel tree The trickiest part has been bringing the works-in-progress forward without spending lots of time babysitting the SCM tools. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bootstrapping into git, commit gripes at me
On Fri, Jul 08, 2005 at 06:08:52PM -0700, Junio C Hamano wrote: > > "MS" == Marc Singer <[EMAIL PROTECTED]> writes: > > MS> Does this preclude symlinking .git? I'd like to keep one .git which > MS> is mirrored from the net and allow for more than one working > MS> directory. > > I think people typically do this by symlinking .git/objects, not > .git/ itself. > > Presumably the reason you would want to have more than one > working tree is so that you can keep more than one topic of > development, one for each working tree, and make commits > independently, right? Which commit is the latest in each work > tree is, unsurprisingly, stored in .git/refs/heads/master file > in each work tree, so usually you would _not_ want to share > things other than .git/objects/ under .git/ directory across > work trees. > > One major downside of this, which I was burned once myself > (which is the reason for me to stop doing it), is that > git-fsck-cache and git-prune-script would not know anything > about the objects in the shared .git/objects reachable from > other work trees, and can happily garbage collect objects > necessary for other work trees. Hmm. Seems, then, that this precludes any sharing at all. It isn't so serious with git as it was wth BK. The latter being disk hungry. I gather that the approved solution is to have complete replicas of the git master from Linus for each line of development. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bootstrapping into git, commit gripes at me
> $ git checkout -f v2.6.11 ;# fixed one > warning: v2.6.11 is not a commit -- not updating your HEAD > $ git commit ;# to have his own baseline at v2.6.11 > $ git-apply --index --stat --summary --apply <../old-patch-file > $ : do the usual tests > $ git commit ;# create a commit based on the baseline v2.6.11 Interesting note. I tried the git-apply command and found that it complained and wouldn't succeed. [EMAIL PROTECTED] ~...embedded/linux-2.6 > git-apply --index --stat --summary --apply < ../ms16/ide.patch error: patch failed: drivers/ide/ide-io.c:129 error: drivers/ide/ide-io.c: patch does not apply Yet, patch does apply. [EMAIL PROTECTED] ~...embedded/linux-2.6 > patch -p1 < ../ms16/ide.patch patching file drivers/ide/arm/ide_arm.c patching file drivers/ide/arm/ide-lpd7952x.c patching file drivers/ide/arm/ide-lpd7a40x.c patching file drivers/ide/arm/Makefile patching file drivers/ide/ide-disk.c Hunk #1 succeeded at 282 (offset 41 lines). Hunk #2 succeeded at 294 (offset 41 lines). patching file drivers/ide/ide-io.c Hunk #1 succeeded at 96 with fuzz 2 (offset -33 lines). Hunk #2 succeeded at 1227 (offset 189 lines). Hunk #3 succeeded at 1388 (offset 189 lines). Hunk #4 succeeded at 1689 (offset 187 lines). patching file drivers/ide/ide-iops.c patching file drivers/ide/ide-probe.c Hunk #1 succeeded at 422 (offset 51 lines). Hunk #2 succeeded at 784 (offset 59 lines). Hunk #3 succeeded at 847 (offset 59 lines). Hunk #4 succeeded at 1112 (offset 64 lines). Hunk #5 succeeded at 1172 (offset 64 lines). patching file drivers/ide/Kconfig Hunk #1 succeeded at 272 (offset -1 lines). Hunk #2 succeeded at 781 (offset 5 lines). patching file drivers/ide/legacy/ht6560b.c patching file drivers/ide/legacy/qd65xx.c patching file drivers/ide/pci/ns87415.c patching file drivers/ide/pci/sl82c105.c patching file drivers/ide/pci/trm290.c patching file drivers/ide/ppc/pmac.c Hunk #1 succeeded at 572 (offset 61 lines). Hunk #2 succeeded at 596 (offset 61 lines). patching file include/linux/ide.h Hunk #1 succeeded at 961 (offset 1 line). Hunk #2 succeeded at 1497 (offset -14 lines). It should be obvious that a patch that doesn't apply cleanly, i.e. without rejects, is still useful to apply so that I can fix the places where it fails. o Why does patch work and git-apply fail? o Is there a way to force git to apply and safe the rejects? - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Bootstrapping into git, commit gripes at me
In working through a usage example on my way to producing bonafide patches, I've found that commit is complaining. Here's what I've done. o Fetched and built cogito-0.12 o Fetched (rsync) Linus' tree o Created a working directory, linux-2.6 o linked .git in the working directory to the .git directory fetched from the net. o # git checkout -f v2.6.11 o # cat ../old-patch-file | patch -p1 Then, according to Jeff's instructions, I have to perform get-update-cache with the name of each file I changed. Is that really the way? o # git-update-cache LIST_OF_CHANGED_FILES Now I commit. o # git commit I am presented with an editor session with the list of changed files already present. IfI add a comment and leave the editor, I'm told fatal: 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c is not a valid 'commit' object If I don't edit the comment, it doesn't give an error but I don't think the changes are committed because I can invoke git commit again. Am I off track? Cheers. P.S. vger isn't letting me subscribe ATM. Please copy me with replies. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
