* Partially private repository?
From: Daed Lee @ 2010-01-29 22:01 UTC (permalink / raw)
To: git
Hi, I'm wondering if git can handle the following use. I have a
project that started as private experiment, but has morphed into
something I'd like to release publicly. I want to give others access
to the repository, but only to commits after a certain cutoff date.
Commits prior to that date have things like hardcoded file paths,
emails, etc. that I'd like to keep private.
I suppose the easiest thing to do would be to create a new repository,
add the project files to it, and make that public, however I'd like to
keep my private commit history along with the public commit history
going forward in a single repository if possible. Is there a way to do
this with git?
Appreciate any pointers in the right direction. Thanks.
^ permalink raw reply
* Re: master^ is not a local branch -- huh?!?
From: Sverre Rabbelier @ 2010-01-29 22:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, Git List, Ron1, Jacob Helwig
In-Reply-To: <7viqakh8ty.fsf@alter.siamese.dyndns.org>
Heya,
On Fri, Jan 29, 2010 at 22:58, Junio C Hamano <gitster@pobox.com> wrote:
> Sverre's explanation does not match reality.
Heh, that's the second time I messed up explaining this new feature,
maybe I should stop doing that... eh... my bad.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: master^ is not a local branch -- huh?!?
From: Junio C Hamano @ 2010-01-29 21:59 UTC (permalink / raw)
To: Ron Garret; +Cc: git
In-Reply-To: <ron1-A90E72.13434029012010@news.gmane.org>
Ron Garret <ron1@flownet.com> writes:
> Of course it's possible. It git can complain and do something (which is
> what it does now) then it can just as easily complain and do nothing.
It is not complaining. It is telling you that you might have triggered an
advanced feature you may not be prepared to use yet.
So forbidding the advanced feature from everybody won't be a solution.
^ permalink raw reply
* Re: master^ is not a local branch -- huh?!?
From: Junio C Hamano @ 2010-01-29 21:58 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Sverre Rabbelier, Git List, Ron1, Jacob Helwig
In-Reply-To: <alpine.LFD.2.00.1001291641200.1681@xanadu.home>
Nicolas Pitre <nico@fluxnic.net> writes:
> What purpose does this "feature" serve? Making sure people remain
> stupid and get even more confused when the special dwimery doesn't work
> because they don't know the difference between a local branch and a
> remote tracking branch?
>
> And now people will be left wondering why after a fetch they don't get
> the latest stuff when they do "git checkout topic" again. Is this any
> better?
Sverre's explanation does not match reality.
We used to just say "topic is not a rev nor path" and failed when the user
said "git checkout topic". And the magic kicks in when there is only one
"remotes/*/topic".
Because this cannot be any request other than to check out a local branch
"topic", and because there is no place more sensible than the "topic"
taken from the "origin" (as that is the sole place that has "topic"), it
dwims as a shorthand for "checkout -b topic origin/topic" and tells you
that it did so.
So people _has_ to still know that local branches are the only thing they
can check out (iow, "checkout topic" is not a request to check out a
remote tracking branch).
^ permalink raw reply
* Re: master^ is not a local branch -- huh?!?
From: Junio C Hamano @ 2010-01-29 21:54 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Ron Garret, git
In-Reply-To: <fabb9a1e1001291328s1df443d6jdf0501cda17072de@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> On Fri, Jan 29, 2010 at 22:24, Ron Garret <ron1@flownet.com> wrote:
>> Yes, I read that. But what I'm trying to do is not just *look* at the
>> history, I want to restore my working tree to a previous version. The
>> "Exploring History" section of the docs doesn't say how to do that.
>
> Do you want to restore your working tree only, or also throw away the
> history? If the former, you could look at 'git revert',...
I think he wanted to check paths out of a commit and the set of paths
happened to be "everything".
IOW, "checkout $commit ."
^ permalink raw reply
* Re: master^ is not a local branch -- huh?!?
From: Nicolas Pitre @ 2010-01-29 21:51 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Junio C Hamano, Git List, Ron1, Jacob Helwig
In-Reply-To: <fabb9a1e1001291332w1d161f8at58aa6fe6908bd77f@mail.gmail.com>
On Fri, 29 Jan 2010, Sverre Rabbelier wrote:
> Heya,
>
> On Fri, Jan 29, 2010 at 22:29, Nicolas Pitre <nico@fluxnic.net> wrote:
> > Then who was arguing about making Git more user friendly rather
> > then less?
>
> Using a detached head is a more advanced feature than wanting to
> checkout a remote branch locally, creating a local tracking branch. As
> such, 'git checkout origin/topic' now means the same as 'git checkout
> -t origin/topic', and you can get the old behavior back by doing 'git
> checkout origin/topic^0'.
What purpose does this "feature" serve? Making sure people remain
stupid and get even more confused when the special dwimery doesn't work
because they don't know the difference between a local branch and a
remote tracking branch?
And now people will be left wondering why after a fetch they don't get
the latest stuff when they do "git checkout topic" again. Is this any
better?
> I don't see what the problem is, if you're
> using a detached head you're an advanced enough git user that you can
> remember that you can use '^0' to detach your head.
I don't agree with the assertion that a detached HEAD is for advanced
users only.
> It's not all that uncommon to do 'git checkout HEAD^0' to detach your
> head to the current branch, no?
Certainly way more uncommon than 'git checkout origin/foo', and way less
intuitive.
Nicolas
^ permalink raw reply
* Re: [PATCH] checkout: warn about 'branch name' rather than 'local branch'
From: Ron Garret @ 2010-01-29 21:50 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.LFD.2.00.1001291621020.1681@xanadu.home>
In article <alpine.LFD.2.00.1001291621020.1681@xanadu.home>,
Nicolas Pitre <nico@fluxnic.net> wrote:
> On Fri, 29 Jan 2010, Sverre Rabbelier wrote:
>
> > These days, you can say "git checkout topic" to automagically create
> > a local "topic" branch that forks from "origin/topic" remote tracking
> > branch when you have one, thanks to Dscho's UI improvement ideas. As
> > such it is more appropriate to say that the user is checking out
> > something that is not a branch name, rather than saying it is not a
> > 'local branch'.
> >
> > Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
>
> For the record, I'm providing a NAK. First I don't agree with the UI
> "improvement" if there is no way to check out a remote branch without
> creating soon-to-be-stall local branches with the same name.
>
> Next, the message can be made yet more clear and give the user more of a
> hint with what is going on. Something like:
>
> "%s is not a local branch head: creating a detached HEAD\n"
>
> plus the remaining clue lines. This way people will have a much greater
> chance of understanding what state they're in, and a simple Google
> search for detached HEAD gives you the Git manual page with the needed
> info.
I agree that would be much better.
rg
^ permalink raw reply
* Re: master^ is not a local branch -- huh?!?
From: Junio C Hamano @ 2010-01-29 21:49 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Sverre Rabbelier, Git List, Ron1, Jacob Helwig
In-Reply-To: <alpine.LFD.2.00.1001291614550.1681@xanadu.home>
Nicolas Pitre <nico@fluxnic.net> writes:
>> These days, you can say "git checkout topic" to automagically create a
>> local "topic" branch that forks from "origin/topic" remote tracking branch
>> when you have one, thanks to Dscho's UI improvement ideas (one less
>> reason you may end up on a detached HEAD state without wanting to).
>
> If this is the case then I'm really disappointed.
>
> With all due respects, I don't share Dscho's sentiment about Git's
> alleged non user-friendliness. And I always praised Git's ability to
> use a detached head to check out a remote branch, and never had any
> problem teaching this concept to people. So the above is not a UI
> improvement at all to me.
Just in case you misunderstood...
This is "git checkout topic", not "git checkout origin/topic". The rule
kicks in when you do not have local branch "topic" and there is a unique
"refs/remotes/*/topic". Existing ways to explicitly ask for detaching are
unaffected, so "checkout origin/topic" or "checkout origin/topic^0" do
what you expect.
We used to just say "topic is not a rev nor path" and failed when the user
sayd "git checkout topic".
Because this cannot be any request other than to check out a local branch
"topic", and because there is no place more sensible than the "topic"
taken from the "origin" (as that is the sole place that has "topic"), it
dwims as a shorthand for "checkout -b topic origin/topic" and tells you
that it did so.
^ permalink raw reply
* Re: [PATCH] checkout: warn about 'branch name' rather than 'local branch'
From: Sverre Rabbelier @ 2010-01-29 21:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git List, Ron1, Jacob Helwig
In-Reply-To: <7vvdekh9kb.fsf@alter.siamese.dyndns.org>
Heya,
On Fri, Jan 29, 2010 at 22:42, Junio C Hamano <gitster@pobox.com> wrote:
> I explained why I think that is not solving the real problem. To a user
> faced with an unexpected detached HEAD situation, it is not very important
> to explain how we were forced to detach (i.e. because you didn't tell me
> to switch to a branch).
I agree your patch is better :).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: master^ is not a local branch -- huh?!?
From: Ron Garret @ 2010-01-29 21:43 UTC (permalink / raw)
To: git
In-Reply-To: <8c9a061001291325i4b8898b9m46054040c69f8fc6@mail.gmail.com>
In article <8c9a061001291325i4b8898b9m46054040c69f8fc6@mail.gmail.com>,
Jacob Helwig <jacob.helwig@gmail.com> wrote:
> On Fri, Jan 29, 2010 at 13:16, Ron1 <ron1@flownet.com> wrote:
> > I know that master^ is a commit and not a branch. I thought I was
> > invoking the third variant of git-checkout (as given on the git-checkout
> > man page) and checking out a commit (which the man page calls a
> > tree-ish).
> >
> > In any case, since my question seems to have sparked some discussion,
> > I'd like to offer two observations:
> >
> > 1. Saying "isn't a local branch" is mightily confusing, because it is
> > ambiguous whether the problem is that it isn't a branch or if it isn't
> > local.
> >
> > 2. If I pass something to git checkout (or any other command for that
> > matter) that it expects to be a branch but isn't a branch it would be
> > much better if it just gave an error and did nothing rather than give a
> > (confusing) warning and try to extrapolate the user's intentions.
> > Whatever a user could possibly mean by 'git checkout master^' it is
> > almost certainly not what that command actually does at the moment.
> >
>
> I don't think that #2 would be possible.
Of course it's possible. It git can complain and do something (which is
what it does now) then it can just as easily complain and do nothing.
> My understanding is that
> branches are basically just there as convenient "names" for arbitrary
> commits. In other words (in my understanding): There is no place that
> expects a "branch" where a commit (SHA-1) would not work (and be a
> perfectly valid use).
No, that's not true. Branches have names that are recorded separately
from non-branch commits. It's not a big difference, but it is a
difference.
rg
^ permalink raw reply
* Re: [PATCH] checkout: warn about 'branch name' rather than 'local branch'
From: Junio C Hamano @ 2010-01-29 21:42 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Git List, Ron1, Jacob Helwig
In-Reply-To: <1264799342-11093-1-git-send-email-srabbelier@gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> These days, you can say "git checkout topic" to automagically create
> a local "topic" branch that forks from "origin/topic" remote tracking
> branch when you have one, thanks to Dscho's UI improvement ideas. As
> such it is more appropriate to say that the user is checking out
> something that is not a branch name, rather than saying it is not a
> 'local branch'.
>
> Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
> ---
>
> Junio, I used part of your reply as the commit message, is that ok?
>
> Only change is s/local branch/branch name/.
I explained why I think that is not solving the real problem. To a user
faced with an unexpected detached HEAD situation, it is not very important
to explain how we were forced to detach (i.e. because you didn't tell me
to switch to a branch).
^ permalink raw reply
* Re: [PATCH] checkout: warn about 'branch name' rather than 'local branch'
From: Nicolas Pitre @ 2010-01-29 21:40 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Junio C Hamano, Git List, Ron1, Jacob Helwig
In-Reply-To: <1264799342-11093-1-git-send-email-srabbelier@gmail.com>
On Fri, 29 Jan 2010, Sverre Rabbelier wrote:
> These days, you can say "git checkout topic" to automagically create
> a local "topic" branch that forks from "origin/topic" remote tracking
> branch when you have one, thanks to Dscho's UI improvement ideas. As
> such it is more appropriate to say that the user is checking out
> something that is not a branch name, rather than saying it is not a
> 'local branch'.
>
> Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
For the record, I'm providing a NAK. First I don't agree with the UI
"improvement" if there is no way to check out a remote branch without
creating soon-to-be-stall local branches with the same name.
Next, the message can be made yet more clear and give the user more of a
hint with what is going on. Something like:
"%s is not a local branch head: creating a detached HEAD\n"
plus the remaining clue lines. This way people will have a much greater
chance of understanding what state they're in, and a simple Google
search for detached HEAD gives you the Git manual page with the needed
info.
Nicolas
^ permalink raw reply
* Re: master^ is not a local branch -- huh?!?
From: Ron Garret @ 2010-01-29 21:40 UTC (permalink / raw)
To: git
In-Reply-To: <fabb9a1e1001291328s1df443d6jdf0501cda17072de@mail.gmail.com>
In article
<fabb9a1e1001291328s1df443d6jdf0501cda17072de@mail.gmail.com>,
Sverre Rabbelier <srabbelier@gmail.com> wrote:
> Heya,
>
> On Fri, Jan 29, 2010 at 22:24, Ron Garret <ron1@flownet.com> wrote:
> > Yes, I read that. But what I'm trying to do is not just *look* at the
> > history, I want to restore my working tree to a previous version. The
> > "Exploring History" section of the docs doesn't say how to do that.
>
> Do you want to restore your working tree only,
Yes.
> or also throw away the history?
No.
> If the former, you could look at 'git revert'
If that's the right answer then the docs needs serious revision. The
docs for "git revert" say that what it does is:
"Given one existing commit, revert the change the patch introduces, and
record a new commit that records it."
which does not sound at all like what I'm trying to do.
All I want to do is copy an old commit to my working tree, nothing else.
I don't want to move my head pointer. I don't want to muck with my
index. I don't want to commit any changes or undo any history. It's a
very simple thing. It ought to be simple to do, but it doesn't seem to
be.
rg
^ permalink raw reply
* Re: master^ is not a local branch -- huh?!?
From: Junio C Hamano @ 2010-01-29 21:35 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Git List, Ron1, Jacob Helwig
In-Reply-To: <fabb9a1e1001291256j71e2c95cic21cb5a6a0cc1fe8@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> On Fri, Jan 29, 2010 at 21:48, Junio C Hamano <gitster@pobox.com> wrote:
>> I think "not a branch" is a good suggestion, whether the target of
>> checkout is "master^" or "origin/topic".
>
> Mhhh, for added clarity, do we want to change it to "branch name"? Since ...
>
> $ git grep "branch name" Documentation/ | wc -l
> 58
>
> ... suggests that we use that in other places as well?
I think the confusion is twofold:
$ git checkout master^
Note: moving to 'master^' which isn't a local branch
If you want to create a new branch from this checkout, you may do so
...
The notice tells us:
- We are moving to 'master^', but it doesn't say what that really means;
- That 'master^' isn't a local branch, but it doesn't say why it matters
if it is a local branch (name) or not.
But what it really should tell new people are:
- The user is no longer on any branch;
- What the implications of not being on any branch are;
Your "branch _name_" suggestion deals with another issue that is of lessor
importance compared to the above two:
- The _reason_ we are detaching HEAD is because 'master^' did not spell a
name of a local branch.
- and perhaps how to be on a branch instead of detaching the head like so.
Compare the current output from "git checkout $commit" with output from
"git checkout topic" when you don't have a local branch "topic" but have a
unique remote tracking branch with the same name from a remote, namely
"origin" (that's the UI improvement from Dscho I mentioned in the previous
message):
$ git checkout topic
Branch topic set up to track remote branch topic from origin.
Switched to a new branch 'topic'
which very clearly explains what is going on.
The current advisory message tells you what to do to create a new branch,
but doesn't explain why you might want to do so (or what is the downside
of not doing so) in the first place. That adds to frustration for new
people.
So how about this strawman?
$ git checkout origin/topic
Note: checking out commit 'origin/topic'.
You are no longer on any branch. You can look around, make changes and
record them in new commits, but any new commit you make from now on will
be lost when you check out another branch. If you want to create a new
branch from this state to keep them, you may do so (now or later) by
using -b with the checkout command again. Example:
git checkout -b new_branch_name
HEAD is now at f423ef5... tests: allow user to specify trash direc...
and hide the lines from "Note: checking out..." to the blank line before
"HEAD is now at" inside advice.detachedHEAD, so that people who know what
detached head is and want to take advantage of it to experiment without
having to worry about cleaning up will have to see only:
$ git checkout origin/topic
HEAD is now at f423ef5... tests: allow user to specify trash direc...
diff --git a/advice.c b/advice.c
index 936d98b..0be4b5f 100644
--- a/advice.c
+++ b/advice.c
@@ -5,6 +5,7 @@ int advice_status_hints = 1;
int advice_commit_before_merge = 1;
int advice_resolve_conflict = 1;
int advice_implicit_identity = 1;
+int advice_detached_head = 1;
static struct {
const char *name;
@@ -15,6 +16,7 @@ static struct {
{ "commitbeforemerge", &advice_commit_before_merge },
{ "resolveconflict", &advice_resolve_conflict },
{ "implicitidentity", &advice_implicit_identity },
+ { "detachedhead", &advice_detached_head },
};
int git_default_advice_config(const char *var, const char *value)
diff --git a/advice.h b/advice.h
index 9b7a3ad..3244ebb 100644
--- a/advice.h
+++ b/advice.h
@@ -8,6 +8,7 @@ extern int advice_status_hints;
extern int advice_commit_before_merge;
extern int advice_resolve_conflict;
extern int advice_implicit_identity;
+extern int advice_detached_head;
int git_default_advice_config(const char *var, const char *value);
diff --git a/builtin-checkout.c b/builtin-checkout.c
index 5277817..0719e54 100644
--- a/builtin-checkout.c
+++ b/builtin-checkout.c
@@ -522,8 +522,16 @@ static void update_refs_for_switch(struct checkout_opts *opts,
update_ref(msg.buf, "HEAD", new->commit->object.sha1, NULL,
REF_NODEREF, DIE_ON_ERR);
if (!opts->quiet) {
- if (old->path)
- fprintf(stderr, "Note: moving to '%s' which isn't a local branch\nIf you want to create a new branch from this checkout, you may do so\n(now or later) by using -b with the checkout command again. Example:\n git checkout -b <new_branch_name>\n", new->name);
+ if (old->path && advice_detached_head)
+ fprintf(stderr,
+"Note: checking out commit '%s'.\n"
+"You are no longer on any branch. You can look around, make changes and\n"
+"record them in new commits, but any new commit you make from now on will\n"
+"be lost when you check out another branch. If you want to create a new\n"
+"branch from this state to keep them, you may do so (now or later) by\n"
+"using -b with the checkout command again. Example:\n\n"
+" git checkout -b new_branch_name\n\n",
+ new->name);
describe_detached_head("HEAD is now at", new->commit);
}
}
^ permalink raw reply related
* Re: master^ is not a local branch -- huh?!?
From: Ron Garret @ 2010-01-29 21:34 UTC (permalink / raw)
To: git
In-Reply-To: <op.u7a909hf4oyyg1@alvarezp-ws>
In article <op.u7a909hf4oyyg1@alvarezp-ws>,
"Octavio Alvarez" <alvarezp@alvarezp.ods.org> wrote:
> On Fri, 29 Jan 2010 12:20:46 -0800, Ron1 <ron1@flownet.com> wrote:
>
> > [ron@mickey]$ git checkout master
> > Already on 'master'
> > [ron@mickey]$ git checkout master^
> > Note: moving to 'master^' which isn't a local branch
> > If you want to create a new branch from this checkout, you may do so
> > (now or later) by using -b with the checkout command again. Example:
> > git checkout -b <new_branch_name>
> > HEAD is now at 7be05e0... test
> > [ron@mickey]$ git branch
> > * (no branch)
> > master
> > [ron@mickey]$
> >
> > Huh?!?
> >
> > This is a test repository which has never been pulled from nor pushed to
> > anywhere. So how is it possible that I have a non-local branch?
>
> "Is a non-local branch" is not the same as "is not a local branch".
>
> Think "branches" as tags that advance when you commit over them.
>
> If you do gitk --all, only those commits with a green tag are
> "branches".
>
> It means that if you switch to master^ and commit, your commit will
> be applied but not tracked (since there is not any branch to advance).
>
> You would need to do git checkout -b 'new_branch', and then commit.
> Now, new_branch will advance with your new commit.
OK, I think I understand that.
Here's the thing: I can do this:
git checkout commit-id filename
and restore a particular revision of a particular file to my working
tree without affecting my HEAD pointer. I would expect then that
git checkout commit-id
with no filename would do the same thing, except restore the entire tree
from that commit (including deleting files that didnt' exist then). And
indeed it does that (or at least appears to -- I haven't explored this
in depth), except that it DOES move my HEAD pointer to this weird
non-branch thing.
Here's what I think would be the correct behavior:
[ron@mickey]$ git checkout master^
"WARNING: master^ is not a branch. It is a commit on the master branch.
Since the the commit you are asking for is on the same branch as your
current HEAD pointer, here's what I'm going to do:
1. Copy the master^ commit to your working tree
2. Leave your HEAD pointer where is was (i.e. pointing to the head
of the master branch).
If this is not what you wanted, you can undo it by typing "git checkout
HEAD". Also, in the future, you can avoid this warning by typing ...
instead.
Or something like that.
rg
^ permalink raw reply
* Re: master^ is not a local branch -- huh?!?
From: Sverre Rabbelier @ 2010-01-29 21:32 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, Git List, Ron1, Jacob Helwig
In-Reply-To: <alpine.LFD.2.00.1001291628510.1681@xanadu.home>
Heya,
On Fri, Jan 29, 2010 at 22:29, Nicolas Pitre <nico@fluxnic.net> wrote:
> Then who was arguing about making Git more user friendly rather
> then less?
Using a detached head is a more advanced feature than wanting to
checkout a remote branch locally, creating a local tracking branch. As
such, 'git checkout origin/topic' now means the same as 'git checkout
-t origin/topic', and you can get the old behavior back by doing 'git
checkout origin/topic^0'. I don't see what the problem is, if you're
using a detached head you're an advanced enough git user that you can
remember that you can use '^0' to detach your head. It's not all that
uncommon to do 'git checkout HEAD^0' to detach your head to the
current branch, no?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: master^ is not a local branch -- huh?!?
From: Nicolas Pitre @ 2010-01-29 21:29 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Junio C Hamano, Git List, Ron1, Jacob Helwig
In-Reply-To: <fabb9a1e1001291321v708c7cb4sec8e944f336d04fd@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 592 bytes --]
On Fri, 29 Jan 2010, Sverre Rabbelier wrote:
> Heya,
>
> On Fri, Jan 29, 2010 at 22:20, Nicolas Pitre <nico@fluxnic.net> wrote:
> > With all due respects, I don't share Dscho's sentiment about Git's
> > alleged non user-friendliness. And I always praised Git's ability to
> > use a detached head to check out a remote branch, and never had any
> > problem teaching this concept to people. So the above is not a UI
> > improvement at all to me.
>
> I think 'git checkout origin/master^0' still works?
Then who was arguing about making Git more user friendly rather
then less?
Nicolas
^ permalink raw reply
* Re: master^ is not a local branch -- huh?!?
From: Sverre Rabbelier @ 2010-01-29 21:28 UTC (permalink / raw)
To: Ron Garret; +Cc: git
In-Reply-To: <ron1-953427.13240429012010@news.gmane.org>
Heya,
On Fri, Jan 29, 2010 at 22:24, Ron Garret <ron1@flownet.com> wrote:
> Yes, I read that. But what I'm trying to do is not just *look* at the
> history, I want to restore my working tree to a previous version. The
> "Exploring History" section of the docs doesn't say how to do that.
Do you want to restore your working tree only, or also throw away the
history? If the former, you could look at 'git revert', if the latter,
'git reset --hard' could be what you need (warning: the latter is a
destructive command that will let you _throw away history_).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: master^ is not a local branch -- huh?!?
From: Jacob Helwig @ 2010-01-29 21:25 UTC (permalink / raw)
To: Ron1; +Cc: git
In-Reply-To: <ron1-F6943B.13162129012010@news.gmane.org>
On Fri, Jan 29, 2010 at 13:16, Ron1 <ron1@flownet.com> wrote:
> I know that master^ is a commit and not a branch. I thought I was
> invoking the third variant of git-checkout (as given on the git-checkout
> man page) and checking out a commit (which the man page calls a
> tree-ish).
>
> In any case, since my question seems to have sparked some discussion,
> I'd like to offer two observations:
>
> 1. Saying "isn't a local branch" is mightily confusing, because it is
> ambiguous whether the problem is that it isn't a branch or if it isn't
> local.
>
> 2. If I pass something to git checkout (or any other command for that
> matter) that it expects to be a branch but isn't a branch it would be
> much better if it just gave an error and did nothing rather than give a
> (confusing) warning and try to extrapolate the user's intentions.
> Whatever a user could possibly mean by 'git checkout master^' it is
> almost certainly not what that command actually does at the moment.
>
I don't think that #2 would be possible. My understanding is that
branches are basically just there as convenient "names" for arbitrary
commits. In other words (in my understanding): There is no place that
expects a "branch" where a commit (SHA-1) would not work (and be a
perfectly valid use).
^ permalink raw reply
* Re: master^ is not a local branch -- huh?!?
From: Ron Garret @ 2010-01-29 21:24 UTC (permalink / raw)
To: git
In-Reply-To: <hjvgs1$rep$1@ger.gmane.org>
In article <hjvgs1$rep$1@ger.gmane.org>,
"Scott R. Godin" <scottg.wp-hackers@mhg2.com> wrote:
> On 01/29/2010 03:20 PM, Ron1 wrote:
> > [ron@mickey]$ git checkout master
> > Already on 'master'
> > [ron@mickey]$ git checkout master^
> > Note: moving to 'master^' which isn't a local branch
> > If you want to create a new branch from this checkout, you may do so
> > (now or later) by using -b with the checkout command again. Example:
> > git checkout -b<new_branch_name>
> > HEAD is now at 7be05e0... test
> > [ron@mickey]$ git branch
> > * (no branch)
> > master
> > [ron@mickey]$
> >
> > Huh?!?
> >
> > This is a test repository which has never been pulled from nor pushed to
> > anywhere. So how is it possible that I have a non-local branch?
> >
> > Thanks,
> > rg
> >
>
> I believe what you're seeing is known as a detached head (see
> <http://www.kernel.org/pub/software/scm/git/docs/git-checkout.html>
> though I could be wrong about this.)
>
> I think you may have intended to do git checkout HEAD^ or something
> similar?
Yes, in fact that is exactly what I am trying to do. But that has the
same result.
> basically what you did was (I think) checkout (or attempt to
> checkout) the parent commit on master.
Yes. I posted it that way simply because 'git commit HEAD' depends on
what HEAD is. If HEAD is the head of master (which it was) then the
result is the same.
>
> this may offer some additional food for thought:
> <http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html#_exploring_h
> istory>
Yes, I read that. But what I'm trying to do is not just *look* at the
history, I want to restore my working tree to a previous version. The
"Exploring History" section of the docs doesn't say how to do that.
rg
^ permalink raw reply
* Re: master^ is not a local branch -- huh?!?
From: Sverre Rabbelier @ 2010-01-29 21:21 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, Git List, Ron1, Jacob Helwig
In-Reply-To: <alpine.LFD.2.00.1001291614550.1681@xanadu.home>
Heya,
On Fri, Jan 29, 2010 at 22:20, Nicolas Pitre <nico@fluxnic.net> wrote:
> With all due respects, I don't share Dscho's sentiment about Git's
> alleged non user-friendliness. And I always praised Git's ability to
> use a detached head to check out a remote branch, and never had any
> problem teaching this concept to people. So the above is not a UI
> improvement at all to me.
I think 'git checkout origin/master^0' still works?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] checkout: Fix test for s/local branch/branch name/ change.
From: Sverre Rabbelier @ 2010-01-29 21:20 UTC (permalink / raw)
To: Jacob Helwig; +Cc: Junio C Hamano, Git List, Ron1
In-Reply-To: <1264799942-4531-1-git-send-email-jacob.helwig@gmail.com>
Heya,
On Fri, Jan 29, 2010 at 22:19, Jacob Helwig <jacob.helwig@gmail.com> wrote:
> This should probably be squashed into Sverre Rabbelier's change, if this is
> decided as the way to go.
Ah, excellent point, apologies :(. I saw it show up when I grepped for
the message, not sure why I didn't do anything with that.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: master^ is not a local branch -- huh?!?
From: Nicolas Pitre @ 2010-01-29 21:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sverre Rabbelier, Git List, Ron1, Jacob Helwig
In-Reply-To: <7veil8iqnj.fsf@alter.siamese.dyndns.org>
On Fri, 29 Jan 2010, Junio C Hamano wrote:
> Sverre Rabbelier <srabbelier@gmail.com> writes:
>
> >> master^ is a commit (the first parent of master), not a branch (local
> >> or otherwise).
> >
> > Perhaps we should change the message to say "not a branch" if it's not
> > a reference to a remote branch? Or simply changing the text to "not a
> > (local) branch"?
>
> I think "not a branch" is a good suggestion, whether the target of
> checkout is "master^" or "origin/topic".
>
> These days, you can say "git checkout topic" to automagically create a
> local "topic" branch that forks from "origin/topic" remote tracking branch
> when you have one, thanks to Dscho's UI improvement ideas (one less
> reason you may end up on a detached HEAD state without wanting to).
If this is the case then I'm really disappointed.
With all due respects, I don't share Dscho's sentiment about Git's
alleged non user-friendliness. And I always praised Git's ability to
use a detached head to check out a remote branch, and never had any
problem teaching this concept to people. So the above is not a UI
improvement at all to me.
Nicolas
^ permalink raw reply
* [PATCH] checkout: Fix test for s/local branch/branch name/ change.
From: Jacob Helwig @ 2010-01-29 21:19 UTC (permalink / raw)
To: Junio C Hamano, Git List, Ron1, Sverre Rabbelier; +Cc: Jacob Helwig
In-Reply-To: <1264799342-11093-1-git-send-email-srabbelier@gmail.com>
Signed-off-by: Jacob Helwig <jacob.helwig@gmail.com>
---
This should probably be squashed into Sverre Rabbelier's change, if this is
decided as the way to go.
t/t7201-co.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/t7201-co.sh b/t/t7201-co.sh
index 6442f71..b6e3216 100755
--- a/t/t7201-co.sh
+++ b/t/t7201-co.sh
@@ -171,7 +171,7 @@ test_expect_success 'checkout to detach HEAD' '
git checkout -f renamer && git clean -f &&
git checkout renamer^ 2>messages &&
(cat >messages.expect <<EOF
-Note: moving to '\''renamer^'\'' which isn'\''t a local branch
+Note: moving to '\''renamer^'\'' which isn'\''t a branch name
If you want to create a new branch from this checkout, you may do so
(now or later) by using -b with the checkout command again. Example:
git checkout -b <new_branch_name>
--
1.6.6.1
^ permalink raw reply related
* [PATCH] checkout: warn about 'branch name' rather than 'local branch'
From: Sverre Rabbelier @ 2010-01-29 21:09 UTC (permalink / raw)
To: Junio C Hamano, Git List, Ron1, Jacob Helwig; +Cc: Sverre Rabbelier
In-Reply-To: <fabb9a1e1001291256j71e2c95cic21cb5a6a0cc1fe8@mail.gmail.com>
These days, you can say "git checkout topic" to automagically create
a local "topic" branch that forks from "origin/topic" remote tracking
branch when you have one, thanks to Dscho's UI improvement ideas. As
such it is more appropriate to say that the user is checking out
something that is not a branch name, rather than saying it is not a
'local branch'.
Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
---
Junio, I used part of your reply as the commit message, is that ok?
Only change is s/local branch/branch name/.
builtin-checkout.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-checkout.c b/builtin-checkout.c
index 5277817..4b34314 100644
--- a/builtin-checkout.c
+++ b/builtin-checkout.c
@@ -523,7 +523,7 @@ static void update_refs_for_switch(struct checkout_opts *opts,
REF_NODEREF, DIE_ON_ERR);
if (!opts->quiet) {
if (old->path)
- fprintf(stderr, "Note: moving to '%s' which isn't a local branch\nIf you want to create a new branch from this checkout, you may do so\n(now or later) by using -b with the checkout command again. Example:\n git checkout -b <new_branch_name>\n", new->name);
+ fprintf(stderr, "Note: moving to '%s' which isn't a branch name\nIf you want to create a new branch from this checkout, you may do so\n(now or later) by using -b with the checkout command again. Example:\n git checkout -b <new_branch_name>\n", new->name);
describe_detached_head("HEAD is now at", new->commit);
}
}
--
1.6.6.rc1.56.gaea25.dirty
^ permalink raw reply related
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