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,
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 an
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 t
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 s
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 s
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 (
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 cre
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 wit
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 wil
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 ha
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/
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
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
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
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.
>
>
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
>
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 h
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 omi
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 t
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
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
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 wo
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, t
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 a
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 doin
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
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 cac
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
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
> "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
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
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 peop
> $ 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
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 .g
34 matches
Mail list logo
