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
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
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
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/head-name
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
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
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
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
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
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
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
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
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,
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
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
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:
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
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
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
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.
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 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
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
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
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
25 matches
Mail list logo
