* Re: git-p4: Fix sync errors due to new server version
From: Junio C Hamano @ 2010-02-01 20:47 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: David Aguilar, simon, git, pal_engstad
In-Reply-To: <alpine.LFD.2.00.1002011455440.1681@xanadu.home>
Thanks; will queue it to 'master'.
^ permalink raw reply
* Re: [PATCH] Fix typos in technical documentation.
From: Junio C Hamano @ 2010-02-01 20:55 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Ralf Wildenhues, git
In-Reply-To: <vpqsk9m5nt1.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> Ralf Wildenhues <Ralf.Wildenhues@gmx.de> writes:
>
>> Signed-off-by: Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
>> ---
>>
>> Hi there,
>>
>> stumbled upon a couple of these, then grepped for the rest
>> in Documentation/.
>
> Nice catches!
Yeah, applied. Thanks.
^ permalink raw reply
* Re: [PATCH 1/2] configure: Allow GIT_ARG_SET_PATH to handle --without-PROGRAM
From: Junio C Hamano @ 2010-02-01 21:14 UTC (permalink / raw)
To: Ben Walton; +Cc: git, gitster
In-Reply-To: <1264990505-29578-2-git-send-email-bwalton@artsci.utoronto.ca>
Ben Walton <bwalton@artsci.utoronto.ca> writes:
> Add an optional second argument to both GIT_ARG_SET_PATH and
> GIT_CONF_APPEND_PATH such that any value of the second argument will
> enable configure to set NO_$PROGRAM in addition to an empty
> $PROGRAM_PATH. This is initially useful for allowing configure to
> disable the use of python, as the remote helper code has nothing
> leveraging it yet.
>
> The Makefile already recognizes NO_PYTHON, but configure provided no
> way to set it appropriately.
>
> Signed-off-by: Ben Walton <bwalton@artsci.utoronto.ca>
> ---
Interesting.
I noticed that even without this patch we seem to honor --without-tcltk
just fine and wondered why. It turns out that we already do the right
thing when TCLTK_PATH is empty to set NO_TCLTK in our Makefile, but we at
the same time have a long custom code in configure.ac to support tcltk.
Perhaps we can clean-up with-/without-tcltk part in configure.ac using
this?
^ permalink raw reply
* Re: [PATCH 1/2] configure: Allow GIT_ARG_SET_PATH to handle --without-PROGRAM
From: Ben Walton @ 2010-02-01 21:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwrywu08v.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 586 bytes --]
Excerpts from Junio C Hamano's message of Mon Feb 01 16:14:40 -0500 2010:
> Perhaps we can clean-up with-/without-tcltk part in configure.ac using
> this?
Sure and I'd be happy to do this.
I noticed (after I sent the patches) that NO_PYTHON is set in the
Makefile automatically if --with-python= is used (leaving PYTHON_PATH
set to null). I prefer the nicer --without-python personally.
I'll fix up the tcltk option and scan for others that might need
similar treatment.
Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Better cooperation between checkouts and stashing
From: Markus Elfring @ 2010-02-01 21:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhbq0wuy6.fsf@alter.siamese.dyndns.org>
> But the thing is, that starting point is not quite correct.
Thanks for your detailed explanations.
> I actually have explained this at least a few times here in the past:
>
> http://thread.gmane.org/gmane.comp.version-control.git/77700/focus=77708
>
I am also very interested in the three use cases that were mentioned in
the discussion for the topic "Switching branches without committing
changes".
> but I don't see anything that states clearly that "checkout" is designed
> to carry your local changes across in any documentation (I gave a cursory
> look to the user manual, tutorial and checkout manual page).
I find it interesting that these descriptions might need still a few
more clarifications about the involved relationships.
> - Internally run 'git stash', then run 'git checkout other-branch'.
>
I imagine that this case is useful because of usual work interruptions
in software development. A developer tries to bring various tasks
forward in parallel. Branches will be switched often with unfinished
work that needs to be kept before the reactivation of another task.
Regards,
Markus
^ permalink raw reply
* Re: master^ is not a local branch -- huh?!?
From: Steve Diver @ 2010-02-01 22:34 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Junio C Hamano, Jay Soffian, Mark Lodato, Sverre Rabbelier,
Git List, Ron1, Jacob Helwig
In-Reply-To: <alpine.LFD.2.00.1002011309020.1681@xanadu.home>
On 1 February 2010 18:12, Nicolas Pitre <nico@fluxnic.net> wrote:
> On Mon, 1 Feb 2010, Junio C Hamano wrote:
>
>> I do not think we need yet another term "scratchpad" for this, but what is
>> important is that both introductory and full documentation explain the
>> detached HEAD well.
>>
>> Currently we say:
>>
>> Detached HEAD
>> -------------
>>
>> It is sometimes useful to be able to 'checkout' a commit that is
>> not at the tip of one of your branches. The most obvious
>> example is to check out the commit at a tagged official release
>> point, like this:
>>
>> ------------
>> $ git checkout v2.6.18
>> ------------
>>
>> Earlier versions of git did not allow this and asked you to
>> create a temporary branch using the `-b` option, but starting from
>> version 1.5.0, the above command 'detaches' your HEAD from the
>> current branch and directly points at the commit named by the tag
>> (`v2.6.18` in the example above).
>>
>> If read carefully (some may argue that it does not need a very careful
>> reading to get it, though), this hints that "detached HEAD" state is a
>> substitute for using a temporary branch, but it may not be strong enough.
>>
>> I thought that a documentation update in this area was already planned?
A "temporary branch" is probably the simplest description, and would
make it easier to grasp the concept in plain language for those that
are new to Git without glazing over.
Is how it worked pre version 1.5.0 now moot in terms of reference?
Probably the first encounter a user might have is when they arrive at
a detached HEAD situation and receive the message that prompted Ron
Garret to start this thread. The concept of an automatic temporary
branch might be easier to understand from the outset without needing
reference to the "old ways" ;)
As an aside, I believe a common misconception is for a user to think
they are checking out a single file revision which could be the most
likely mechanism to lead them into an inadvertent detached HEAD state.
Any improvement in both the first line message and the full
documentation would be most helpful.
>
> Jay Soffian (added to CC) agreed to augment the documentation with the
> comprehensive explanation he posted to the list lately.
>
That is good news indeed.
Steve
^ permalink raw reply
* Re: Better cooperation between checkouts and stashing
From: Eugene Sajine @ 2010-02-01 22:44 UTC (permalink / raw)
To: Markus Elfring; +Cc: Junio C Hamano, git, Eugene Sajine
In-Reply-To: <4B674E36.40708@web.de>
>
> I imagine that this case is useful because of usual work interruptions
>
> in software development. A developer tries to bring various tasks
>
> forward in parallel. Branches will be switched often with unfinished
>
> work that needs to be kept before the reactivation of another task.
>
Aren't this and similar statements based on a general problem of
people being afraid to commit, because CVS/SVN taught them to be
affraid? We are in progress of migrating from CVS to GIT and this is
one of the things i'm desperately fighting with.
In Git Commit doesn't equal Share (it does in CVS), so why not to
commit and save your work in progress and switch branches painlessly?
Thanks,
Eugene
^ permalink raw reply
* Re: master^ is not a local branch -- huh?!?
From: Ron Garret @ 2010-02-01 22:52 UTC (permalink / raw)
To: git
In-Reply-To: <87aavsu9b3.fsf@osv.gnss.ru>
In article <87aavsu9b3.fsf@osv.gnss.ru>, Sergei Organov <osv@javad.com>
wrote:
> Junio C Hamano <gitster@pobox.com> writes:
> > Steve Diver <squelch2@googlemail.com> writes:
>
> [...]
>
> > If read carefully (some may argue that it does not need a very careful
> > reading to get it, though), this hints that "detached HEAD" state is a
> > substitute for using a temporary branch, but it may not be strong
> > enough.
>
> For my rather fresh eye it looks more like unnamed (anonymous?) branch
> than a temporary one. Doesn't detached HEAD behave exactly like a
> regular HEAD but pointing to the tip of an unnamed branch?
I strongly concur with this.
And as long as I'm weighing in, it would also help to prevent confusion
if it were made clear that this unnamed branch doesn't actually come
into existence unless and until you do a commit.
rg
^ permalink raw reply
* [PATCH] resolve-undo.c: silence compiler complaints by casting void * to char *
From: Brandon Casey @ 2010-02-01 23:00 UTC (permalink / raw)
To: gitster; +Cc: git, Brandon Casey
From: Brandon Casey <drafnel@gmail.com>
Some compilers produce errors when arithmetic is attempted on pointers to
void. We want computations done on byte addresses, so cast them to char *
to work them around.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
resolve-undo.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/resolve-undo.c b/resolve-undo.c
index 37d73cd..c259fe6 100644
--- a/resolve-undo.c
+++ b/resolve-undo.c
@@ -75,7 +75,7 @@ struct string_list *resolve_undo_read(void *data, unsigned long size)
lost->util = xcalloc(1, sizeof(*ui));
ui = lost->util;
size -= len;
- data += len;
+ data = (char*) data + len;
for (i = 0; i < 3; i++) {
ui->mode[i] = strtoul(data, &endptr, 8);
@@ -85,7 +85,7 @@ struct string_list *resolve_undo_read(void *data, unsigned long size)
if (size <= len)
goto error;
size -= len;
- data += len;
+ data = (char*) data + len;
}
for (i = 0; i < 3; i++) {
@@ -95,7 +95,7 @@ struct string_list *resolve_undo_read(void *data, unsigned long size)
goto error;
hashcpy(ui->sha1[i], data);
size -= 20;
- data += 20;
+ data = (char*) data + 20;
}
}
return resolve_undo;
--
1.6.6
^ permalink raw reply related
* Re: master^ is not a local branch -- huh?!?
From: Petr Baudis @ 2010-02-01 23:01 UTC (permalink / raw)
To: Ron Garret; +Cc: git
In-Reply-To: <ron1-6F8B85.14520801022010@news.gmane.org>
On Mon, Feb 01, 2010 at 02:52:08PM -0800, Ron Garret wrote:
> In article <87aavsu9b3.fsf@osv.gnss.ru>, Sergei Organov <osv@javad.com>
> wrote:
>
> > Junio C Hamano <gitster@pobox.com> writes:
> > > Steve Diver <squelch2@googlemail.com> writes:
> >
> > [...]
> >
> > > If read carefully (some may argue that it does not need a very careful
> > > reading to get it, though), this hints that "detached HEAD" state is a
> > > substitute for using a temporary branch, but it may not be strong
> > > enough.
> >
> > For my rather fresh eye it looks more like unnamed (anonymous?) branch
> > than a temporary one. Doesn't detached HEAD behave exactly like a
> > regular HEAD but pointing to the tip of an unnamed branch?
>
> I strongly concur with this.
>
> And as long as I'm weighing in, it would also help to prevent confusion
> if it were made clear that this unnamed branch doesn't actually come
> into existence unless and until you do a commit.
That statement is not quite consistent with the Git model. A branch is a
pointer. Detached HEAD is "unnamed" branch pointer (as in, you can refer
to it by the default HEAD alias, but not by any other name). In this
sense, the moment you create detached HEAD, you created the anonymous
branch, and the moment you check out something else, it is gone in a
wisp of smoke again.
The act of committing does not come into the picture at all. Committing
is the act of saving a commit to the database and *updating* the current
branch pointer to point at it. However, it does not affect what branch
pointer is the current one. It is important to realize that:
* Branches refer to commits.
* Commits do not refer to branches!
That is, when you create a commit, it is not _tied_ to a particular
branch. Thus, when you create a commit, you could not have created any
branch, and creating a branch [pointer] is unrelated to creating any
commits.
--
Petr "Pasky" Baudis
If you can't see the value in jet powered ants you should turn in
your nerd card. -- Dunbal (464142)
^ permalink raw reply
* Re: master^ is not a local branch -- huh?!?
From: Nicolas Pitre @ 2010-02-01 23:25 UTC (permalink / raw)
To: Ron Garret; +Cc: git
In-Reply-To: <ron1-6F8B85.14520801022010@news.gmane.org>
On Mon, 1 Feb 2010, Ron Garret wrote:
> In article <87aavsu9b3.fsf@osv.gnss.ru>, Sergei Organov <osv@javad.com>
> wrote:
>
> > Junio C Hamano <gitster@pobox.com> writes:
> > > Steve Diver <squelch2@googlemail.com> writes:
> >
> > [...]
> >
> > > If read carefully (some may argue that it does not need a very careful
> > > reading to get it, though), this hints that "detached HEAD" state is a
> > > substitute for using a temporary branch, but it may not be strong
> > > enough.
> >
> > For my rather fresh eye it looks more like unnamed (anonymous?) branch
> > than a temporary one. Doesn't detached HEAD behave exactly like a
> > regular HEAD but pointing to the tip of an unnamed branch?
>
> I strongly concur with this.
>
> And as long as I'm weighing in, it would also help to prevent confusion
> if it were made clear that this unnamed branch doesn't actually come
> into existence unless and until you do a commit.
Nope. Creating a commit doesn't create any branch. A commit creation
merely adds a new node in the history graph, and links it to the commit
that was the current one before that commit operation. If HEAD is
_attached_ to a branch then the branch pointer is also updated to point
to that new commit. If HEAD is _detached_ then no branch is updated and
HEAD simply carries a direct reference to that new commit.
At a later time you can:
1) Create a new branch pointer which default value is the commit pointed to
by HEAD. This is true whether or not HEAD is detached, but in this
case this is an interesting property.
2) Move HEAD somewhere else by performing a checkout. If HEAD was
detached then its last position is simply forgotten and those
commits that were performed while HEAD was detached, if any, are
simply left dangling and eventually garbage collected. If however a
new branch pointer was created in (1) then those commits won't be
dangling.
In any case, a detached HEAD is not only a temporary branch, it is also
a volatile branch. And in the Git model, it is simply not a branch at
all. Hence the 2 states for HEAD: either detached, or attached to a
branch pointer.
Nicolas
^ permalink raw reply
* Re: master^ is not a local branch -- huh?!?
From: Junio C Hamano @ 2010-02-01 23:37 UTC (permalink / raw)
To: Ron Garret; +Cc: git
In-Reply-To: <ron1-6F8B85.14520801022010@news.gmane.org>
Ron Garret <ron1@flownet.com> writes:
>> For my rather fresh eye it looks more like unnamed (anonymous?) branch
>> than a temporary one. Doesn't detached HEAD behave exactly like a
>> regular HEAD but pointing to the tip of an unnamed branch?
>
> I strongly concur with this.
>
> And as long as I'm weighing in, it would also help to prevent confusion
> if it were made clear that this unnamed branch doesn't actually come
> into existence unless and until you do a commit.
This shows that you are still thinking a branch is a line (or multiple
lines). It is not.
^ permalink raw reply
* Re: [PATCH] resolve-undo.c: silence compiler complaints by casting void * to char *
From: Junio C Hamano @ 2010-02-01 23:44 UTC (permalink / raw)
To: Brandon Casey; +Cc: gitster, git, Brandon Casey
In-Reply-To: <qzbyPiTgRGI0lsxvEmFa0WtwK5ko5snXQDNffxC66y9v0rlie5pcKzGT28WpzfQlFd0OvJNY_jo@cipher.nrlssc.navy.mil>
Thanks for catching this.
In this particular case, I however suspect that it would be cleaner to
declare that the first parameter to resolve_undo_read() is a "char *"
(or even "const char *"), as we are dealing with NUL delimited list of
octal numbers and character strings.
^ permalink raw reply
* Re: master^ is not a local branch -- huh?!?
From: Ron Garret @ 2010-02-01 23:56 UTC (permalink / raw)
To: git
In-Reply-To: <7vwrywplxz.fsf@alter.siamese.dyndns.org>
In article <7vwrywplxz.fsf@alter.siamese.dyndns.org>,
Junio C Hamano <gitster@pobox.com> wrote:
> Ron Garret <ron1@flownet.com> writes:
>
> >> For my rather fresh eye it looks more like unnamed (anonymous?) branch
> >> than a temporary one. Doesn't detached HEAD behave exactly like a
> >> regular HEAD but pointing to the tip of an unnamed branch?
> >
> > I strongly concur with this.
> >
> > And as long as I'm weighing in, it would also help to prevent confusion
> > if it were made clear that this unnamed branch doesn't actually come
> > into existence unless and until you do a commit.
>
> This shows that you are still thinking a branch is a line (or multiple
> lines). It is not.
The git user's guide says it is:
"When we need to be precise, we will use the word "branch" to mean a
line of development..."
But I understand that a branch is not necessarily a line. In general
it's a DAG. I get that.
The manual goes on to say:
"...and "branch head" (or just "head") to mean a reference to the most
recent commit on a branch."
There are two ways this can be interpreted:
1. A commit pointed to by a branch head cannot have any descendants.
Because if it did it would not be the most recent commit on that branch,
and by definition a branch head must point at the most recent commit.
2. Any commit can be considered a branch head for a branch consisting
of (for example) the transitive closure of its ancestors.
(Note that if I were being really strict with my terminology I would
have to say: any commit can be considered the most recent commit for a
branch consisting of... Because a branch head by definition is a
*reference* to a commit, so strictly speaking a commit cannot be a
branch head. The problem is that there are three concepts in play, but
only two terms by which to refer to them.)
I personally think interpretation #1 makes more sense, and is a better
match to most people's intuitions about what it means to be a branch
head. But in neither case does simply moving HEAD "create" a branch.
Even under interpretation 2, all those anonymous branches were there all
along. You don't "create" anything, temporary or otherwise, simply by
moving HEAD.
rg
^ permalink raw reply
* A git-mv question
From: Ron Garret @ 2010-02-02 0:08 UTC (permalink / raw)
To: git
If I do a git-mv *and* edit the file all in one commit, does that get
recorded in a way that allows git to track the change through the
changed file name? In other words, if I do just a git-mv (without
changing the file) git can track that by observing that two differently
named objects in two different commit trees contain the same blob. But
if the file is edited then the blobs will be different. Is git smart
enough to distinguish a git-mv and edit from, say, the equivalent git-rm
and git-add? If so, how does it do it?
Thanks,
rg
^ permalink raw reply
* Re: master^ is not a local branch -- huh?!?
From: Petr Baudis @ 2010-02-02 0:15 UTC (permalink / raw)
To: Ron Garret; +Cc: git
In-Reply-To: <ron1-ABA66E.15563101022010@news.gmane.org>
On Mon, Feb 01, 2010 at 03:56:31PM -0800, Ron Garret wrote:
> In article <7vwrywplxz.fsf@alter.siamese.dyndns.org>,
> Junio C Hamano <gitster@pobox.com> wrote:
> > Ron Garret <ron1@flownet.com> writes:
> > > And as long as I'm weighing in, it would also help to prevent confusion
> > > if it were made clear that this unnamed branch doesn't actually come
> > > into existence unless and until you do a commit.
> >
> > This shows that you are still thinking a branch is a line (or multiple
> > lines). It is not.
>
> The git user's guide says it is:
>
> "When we need to be precise, we will use the word "branch" to mean a
> line of development..."
>
> But I understand that a branch is not necessarily a line. In general
> it's a DAG. I get that.
Again, no. In the most narrow sense, "branch == branch head". Branch is
just a pointer. Which is the reason why your original statement does not
make sense.
We could say that the "branch closure" is the DAG of ancestry of the
commit we point to. We use "branch" in that sense since we have to
express ourselves in natural language, we are not in a calculus class,
there is mapping to various real-world and other-VCS concepts in play,
etc. But in order to use "branch" in the ambiguous sense, you should
first realize what it means in the _strict_ sense, so that you
understand the texts correctly and don't reach wrong conclusions or
create invalid concepts like "branches coming into existence". :-)
--
Petr "Pasky" Baudis
If you can't see the value in jet powered ants you should turn in
your nerd card. -- Dunbal (464142)
^ permalink raw reply
* Re: master^ is not a local branch -- huh?!?
From: Junio C Hamano @ 2010-02-02 0:21 UTC (permalink / raw)
To: Ron Garret; +Cc: git
In-Reply-To: <ron1-6F8B85.14520801022010@news.gmane.org>
Ron Garret <ron1@flownet.com> writes:
>> For my rather fresh eye it looks more like unnamed (anonymous?) branch
>> than a temporary one. Doesn't detached HEAD behave exactly like a
>> regular HEAD but pointing to the tip of an unnamed branch?
>
> I strongly concur with this.
>
> And as long as I'm weighing in, it would also help to prevent confusion
> if it were made clear that this unnamed branch doesn't actually come
> into existence unless and until you do a commit.
After re-reading this three times, I actually cannot tell which one you
think is the confused misconception: (1) unnamed branch does not exist
until you commit, or (2) unnamed branch does exist immediately you
detach.
Let's say you have this history:
---A---B HEAD == master
When drawing commit ancestry in ASCII art, uppercase letters in the
drawing denote commits. Time flows from left to right and we don't write
arrows to show B is a child of A. On the right, above or below commit, we
also write refs (i.e. tags, branches and HEAD). When we say "HEAD ==
master", we mean HEAD is a symref to master ref (if we really want to be
anal, 'refs/heads/master' might be more technically correct but most often
it is clear from the context).
So by the above picture, we mean "There is a history that ends with B,
whose parent is A and it came from somewhere. 'master' branch points at B
and HEAD symref points at 'master' so that is the current branch".
Here is what happens when you make changes and "git commit" it.
(0) Normal case.
---A---B---C HEAD == master
The new state is recorded as a tree, a new commit C is created to wrap
that tree, C is made a child of B (because HEAD pointed at it), and
finally, master is moved to point at that commit C (because HEAD
pointed at 'master').
Notice that two "HEAD pointed at" mean slightly different things in the
above sentence. In the former context of determining the commit to become
the parent of a new commit, we want commit, and "evaluating HEAD by
checking at what it points at" wants to return commit, so even though
technically HEAD at this point would be:
$ cat .git/HEAD
ref: refs/heads/master"
IOW, it points at 'master' branch, we look beyond it and talk about the
commit that is pointed at refs/heads/master.
In the latter, we want to determine if there is a branch we would
want to update to point at the newly created commit, so we look at
HEAD and notice it points at refs/heads/master. We update it,
instead of storing the value of C directly in HEAD.
Now, "git checkout master^0" would do this:
---A---B---C HEAD (detached)
master
There are two pointers.
$ cat .git/HEAD
562d53fa69933b3ade2691b99cbe67722313f43c
$ cat .git/refs/heads/master
562d53fa69933b3ade2691b99cbe67722313f43c
They point at the same commit C (let's pretend 562d53... is C).
You make changes and create a commit. What happens?
(1) A new tree is created and wrapped in a new commit D, whose parent is
C.
D we have not updated
/ any ref yet
---A---B---C
We used the fact that HEAD points at C (in the first "what commit is
pointed?" sense) to determine the parent of D.
(2) We decide what pointer to move to point at this commit. HEAD does not
point at any branch (it directly pointed at commit C), so we do not
move any named branch, but move only HEAD. The end result is:
D HEAD (detached)
/
---A---B---C master
Now you then do "git checkout -b side". What happens?
(3) We create a new branch "side" at the commit HEAD points at (we could
have said "git checkout -b side HEAD"), and make HEAD point at that
branch.
D HEAD == side
/
---A---B---C master
Now, when we say "branch", we do not mean the "line" between C and D.
"master" branch is not a line before A, between A and B and between B and
C concatenated together. "master branch" in git simply points at C in the
above graph.
Especailly, there is no special "master"-ness to the line between B and C.
B can be reached from both 'master' and 'side' branches. A corollary is
that a line between C and D does not have any special 'side'-ness either,
as later you can fork other branches from D.
Similarly, in picture (2) where HEAD is still detached, there is no
special 'HEAD'-ness to the line between C and D.
Similarly in the picture where you had HEAD that was detached that pointed
at C:
---A---B---C HEAD (detached)
there is no HEAD-ness in any of the line segment depicted. The same goes
for all the lines depicted in picture (2); between these two pictures, the
only change made was a commit on the detached HEAD. From the perspective
of "branches", there is no change.
Calling detached HEAD as "temporary" or "anonymous" branch is fine, but
then we should consider the state immediately after detaching the HEAD
equally valid "anonymous" branch as in picture (2).
Putting it in another way, a branch in git is _not_ the name given to line
segments that _led_ to the point the branch points at (i.e. past history).
Think of a branch as the point where your next commit advances from
(i.e. future history).
^ permalink raw reply
* Re: master^ is not a local branch -- huh?!?
From: Junio C Hamano @ 2010-02-02 0:26 UTC (permalink / raw)
To: Ron Garret; +Cc: git
In-Reply-To: <ron1-ABA66E.15563101022010@news.gmane.org>
Ron Garret <ron1@flownet.com> writes:
>> This shows that you are still thinking a branch is a line (or multiple
>> lines). It is not.
>
> The git user's guide says it is:
>
> "When we need to be precise, we will use the word "branch" to mean a
> line of development..."
I think the last paragraph "to put it in another way" in my other message
to you will clear this confusion.
^ permalink raw reply
* Re: A git-mv question
From: Nicolas Pitre @ 2010-02-02 0:29 UTC (permalink / raw)
To: Ron Garret; +Cc: git
In-Reply-To: <ron1-09EE6C.16083801022010@news.gmane.org>
On Mon, 1 Feb 2010, Ron Garret wrote:
> If I do a git-mv *and* edit the file all in one commit, does that get
> recorded in a way that allows git to track the change through the
> changed file name? In other words, if I do just a git-mv (without
> changing the file) git can track that by observing that two differently
> named objects in two different commit trees contain the same blob. But
> if the file is edited then the blobs will be different. Is git smart
> enough to distinguish a git-mv and edit from, say, the equivalent git-rm
> and git-add? If so, how does it do it?
Please see:
http://www.kernel.org/pub/software/scm/git/docs/gitdiffcore.html
Nicolas
^ permalink raw reply
* Re: master^ is not a local branch -- huh?!?
From: Ron Garret @ 2010-02-02 0:45 UTC (permalink / raw)
To: git
In-Reply-To: <20100202001530.GL9553@machine.or.cz>
In article <20100202001530.GL9553@machine.or.cz>,
Petr Baudis <pasky@suse.cz> wrote:
> On Mon, Feb 01, 2010 at 03:56:31PM -0800, Ron Garret wrote:
> > In article <7vwrywplxz.fsf@alter.siamese.dyndns.org>,
> > Junio C Hamano <gitster@pobox.com> wrote:
> > > Ron Garret <ron1@flownet.com> writes:
> > > > And as long as I'm weighing in, it would also help to prevent confusion
> > > > if it were made clear that this unnamed branch doesn't actually come
> > > > into existence unless and until you do a commit.
> > >
> > > This shows that you are still thinking a branch is a line (or multiple
> > > lines). It is not.
> >
> > The git user's guide says it is:
> >
> > "When we need to be precise, we will use the word "branch" to mean a
> > line of development..."
> >
> > But I understand that a branch is not necessarily a line. In general
> > it's a DAG. I get that.
>
> Again, no. In the most narrow sense, "branch == branch head".
The manual specifically contradicts you, so either you are wrong or the
manual is wrong.
Don't forget that what is at issue here is not how git works (I'm pretty
sure everyone is on the same page about that) but how to explain it to
someone who is not already familiar with it. So it's important to use
terminology that is consistent with what the manual says.
> Branch is just a pointer.
No, a branch is not "just" a pointer. At the very least it's a pointer
with a name. The SHA1 hash of a blob is a pointer too. But it's not a
branch. The SHA1 hash of a commit is a pointer too, but if you were to
consider that a branch then "branch" would simply become synonymous with
"commit" and the term would lose its utility.
> Which is the reason why your original statement does not
> make sense.
That remains to be seen. I believe that on the manual's definition of
"branch" my statement not only makes sense, but is actually correct.
> We could say that the "branch closure" is the DAG of ancestry of the
> commit we point to. We use "branch" in that sense since we have to
> express ourselves in natural language, we are not in a calculus class,
> there is mapping to various real-world and other-VCS concepts in play,
> etc. But in order to use "branch" in the ambiguous sense, you should
> first realize what it means in the _strict_ sense, so that you
> understand the texts correctly and don't reach wrong conclusions or
> create invalid concepts like "branches coming into existence". :-)
I am trying to be as strict as I can according to what is in the
documentation.
rg
^ permalink raw reply
* Re: A git-mv question
From: Junio C Hamano @ 2010-02-02 0:46 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Ron Garret, git
In-Reply-To: <alpine.LFD.2.00.1002011927490.1681@xanadu.home>
Nicolas Pitre <nico@fluxnic.net> writes:
> Please see:
>
> http://www.kernel.org/pub/software/scm/git/docs/gitdiffcore.html
Thanks.
Probably it needs a bit of updates to help new people read it.
* It talks about diff-* family. They exist, but what they do can be
triggered also by "diff" wrapper and that is the primary way the users
know about "diff" these days.
* Because it was written to illustrate the low-level diff-* family, it
says "when they are run without -p option". People who only know
Porcelain "diff" need to read as if it said "when run with --raw".
* It does not talk about "log -p" but the discussion applies there as
well (log is a glorified form of diff-tree).
^ permalink raw reply
* Re: master^ is not a local branch -- huh?!?
From: Junio C Hamano @ 2010-02-02 0:53 UTC (permalink / raw)
To: Ron Garret; +Cc: git
In-Reply-To: <ron1-9A9CEA.16452601022010@news.gmane.org>
Ron Garret <ron1@flownet.com> writes:
> The manual specifically contradicts you, so either you are wrong or the
> manual is wrong.
In case you haven't noticed, Pasky is one of the old timers and he knows a
thing or two about the git's world model.
And I do not see a contradiction in what the manual describes and "a
branch is a named pointer to a commit" (although "named" can probably be
omitted as "unnamed pointer" is not useful at the UI level).
^ permalink raw reply
* Re: [PATCH 8/8 v6] gitweb: Add an option to force version match
From: J.H. @ 2010-02-02 1:01 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, John 'Warthog9' Hawley, Petr Baudis
In-Reply-To: <1264890645-28310-9-git-send-email-jnareb@gmail.com>
Starting to pop off the stack, and this came up first. A quick reading
of this, I'd sign-off and agree to patches 1-7 completely.
I'm still going to take issue that this being off by default is the
wrong behavior and leaving this off by default more or less means that
it will never get run and it becomes useless code. If this isn't on by
default, it shouldn't be committed, as I can't think of a legitimate use
case where an admin is going to turn this on.
I'd still argue this needs to be on by default to at least give admins
the explicit warning that if they want to deviate they are taking their
own risks, and that gitweb might not run as expected. Once the warning
is disabled in a configuration file it's not like it's going to be
re-enabled. People loading gitweb from their distro's package
management will likely be in sync properly and will never see this.
Those who are installing gitweb independent of their distro's package
management will at least be warned of the risk, at least until better
error reporting is done and in gitweb.
I've got a slightly modified version of this that re-enables it by
default, it passes t9501 for me.
- John 'Warthog9' Hawley
On 01/30/2010 02:30 PM, Jakub Narebski wrote:
> From: John 'Warthog9' Hawley <warthog9@kernel.org>
>
> This adds $git_versions_must_match variable, which if set to true,
> checks that we are running on the same version of git that we
> shipped with, and if not throw '500 Internal Server Error' error.
> What is checked is the version of gitweb (embedded in building
> gitweb.cgi), against version of runtime git binary used.
>
> Gitweb can usually run with a mismatched git install. This is more
> here to give an obvious warning as to what's going on vs. silently
> failing.
>
> By default this feature is turned off.
>
> Add tests to t9501-gitweb-standalone-http-status.sh that this feature
> works correctly (as expected) if turned on, both in match and no match
> case.
>
> Signed-off-by: John 'Warthog9' Hawley <warthog9@kernel.org>
> Signed-off-by: Jakub Narebski <jnareb@gmail.com>
> ---
> Changes from version from 'Gitweb caching v5' and
> git://git.kernel.org/pub/scm/git/warthog9/gitweb.git gitweb-ml-v5
>
> * Again turned off by default
> * More detailed error description, as requested by Petr 'Pasky' Baudis
> in http://permalink.gmane.org/gmane.comp.version-control.git/137922
> * Which in turn required to set $GITWEB_CONFIG_SYSTEM to be able to
> use its value in error description; otherwise we would get 'Variable
> "$GITWEB_CONFIG_SYSTEM" is not imported' error.
> * Turn off forcing version matching in t/gitweb-lib.sh
> * Add some tests for this feature in t9501-gitweb-standalone-http-status.sh
>
> gitweb/README | 5 +++++
> gitweb/gitweb.perl | 29 ++++++++++++++++++++++++++++-
> t/gitweb-lib.sh | 1 +
> t/t9501-gitweb-standalone-http-status.sh | 27 +++++++++++++++++++++++++++
> 4 files changed, 61 insertions(+), 1 deletions(-)
>
> diff --git a/gitweb/README b/gitweb/README
> index 6c2c8e1..83a25a9 100644
> --- a/gitweb/README
> +++ b/gitweb/README
> @@ -233,6 +233,11 @@ not include variables usually directly set during build):
> If server load exceed this value then return "503 Service Unavaliable" error.
> Server load is taken to be 0 if gitweb cannot determine its value. Set it to
> undefined value to turn it off. The default is 300.
> + * $git_versions_must_match
> + If set to true value, gitweb fails with "500 Internal Server Error" error
> + if the version of the gitweb doesn't match version of the git binary.
> + Gitweb can usually run with a mismatched git install. The default is 0
> + (false).
>
>
> Projects list file format
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index d0c3ff2..e69efeb 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -221,6 +221,9 @@ our %avatar_size = (
> 'double' => 32
> );
>
> +# If it is true, exit if gitweb version and git binary version don't match
> +our $git_versions_must_match = 0;
> +
> # Used to set the maximum load that we will still respond to gitweb queries.
> # If server load exceed this value then return "503 server busy" error.
> # If gitweb cannot determined server load, it is taken to be 0.
> @@ -550,10 +553,10 @@ sub filter_snapshot_fmts {
> }
>
> our $GITWEB_CONFIG = $ENV{'GITWEB_CONFIG'} || "++GITWEB_CONFIG++";
> +our $GITWEB_CONFIG_SYSTEM = $ENV{'GITWEB_CONFIG_SYSTEM'} || "++GITWEB_CONFIG_SYSTEM++";
> if (-e $GITWEB_CONFIG) {
> do $GITWEB_CONFIG;
> } else {
> - our $GITWEB_CONFIG_SYSTEM = $ENV{'GITWEB_CONFIG_SYSTEM'} || "++GITWEB_CONFIG_SYSTEM++";
> do $GITWEB_CONFIG_SYSTEM if -e $GITWEB_CONFIG_SYSTEM;
> }
>
> @@ -583,6 +586,30 @@ sub get_loadavg {
> our $git_version = qx("$GIT" --version) =~ m/git version (.*)$/ ? $1 : "unknown";
> $number_of_git_cmds++;
>
> +# Throw an error if git versions does not match, if $git_versions_must_match is true.
> +if ($git_versions_must_match &&
> + $git_version ne $version) {
> + my $admin_contact =
> + defined $ENV{'SERVER_ADMIN'} ? ", $ENV{'SERVER_ADMIN'}," : '';
> + my $err_msg = <<EOT;
> +<h1 align="center">*** Warning ***</h1>
> +<p>
> +This version of gitweb was compiled for <b>@{[esc_html($version)]}</b>,
> +however git version <b>@{[esc_html($git_version)]}</b> was found on server,
> +and administrator requested strict version checking by setting
> +\$git_versions_must_match to @{[esc_html($git_versions_must_match)]}
> +(true value) in gitweb configuration file,
> +'@{[esc_path(-e $GITWEB_CONFIG ? $GITWEB_CONFIG : $GITWEB_CONFIG_SYSTEM)]}'.
> +</p>
> +<p>
> +Please contact the server administrator${admin_contact} to either configure
> +gitweb to allow mismatched versions, or update git or gitweb installation
> +so that their versions do match.
> +</p>
> +EOT
> + die_error(500, 'Internal server error', $err_msg);
> +}
> +
> $projects_list ||= $projectroot;
>
> if (defined $maxload && get_loadavg() > $maxload) {
> diff --git a/t/gitweb-lib.sh b/t/gitweb-lib.sh
> index 5a734b1..66a3e2d 100755
> --- a/t/gitweb-lib.sh
> +++ b/t/gitweb-lib.sh
> @@ -26,6 +26,7 @@ our \$projects_list = '';
> our \$export_ok = '';
> our \$strict_export = '';
> our \$maxload = undef;
> +our \$git_versions_must_match = 0;
>
> EOF
>
> diff --git a/t/t9501-gitweb-standalone-http-status.sh b/t/t9501-gitweb-standalone-http-status.sh
> index 7590f10..e195f97 100755
> --- a/t/t9501-gitweb-standalone-http-status.sh
> +++ b/t/t9501-gitweb-standalone-http-status.sh
> @@ -133,5 +133,32 @@ cat >>gitweb_config.perl <<\EOF
> our $maxload = undef;
> EOF
>
> +# ======================================================================
> +# check $git_versions_must_match feature
> +# should be last section, just in case
> +cp -f gitweb_config.perl gitweb_config.perl.bak
> +echo 'our $git_versions_must_match = 1;' >>gitweb_config.perl
> +
> +cat <<\EOF >>gitweb_config.perl
> +our $version = "current";
> +EOF
> +test_expect_success 'force version match: no match' '
> + gitweb_run "p=.git" &&
> + grep "Status: 500 Internal Server Error" gitweb.headers &&
> + grep "500 - Internal server error" gitweb.body
> +'
> +test_debug 'cat gitweb.headers'
> +
> +cat <<\EOF >>gitweb_config.perl
> +# must be kept in sync with code in gitweb/gitweb.perl
> +our $version = qx("$GIT" --version) =~ m/git version (.*)$/ ? $1 : "unknown";
> +EOF
> +test_expect_success 'force version match: match' '
> + gitweb_run "p=.git" &&
> + grep "Status: 200 OK" gitweb.headers
> +'
> +test_debug 'cat gitweb.headers'
> +
> +mv -f gitweb_config.perl.bak gitweb_config.perl
>
> test_done
^ permalink raw reply
* Re: master^ is not a local branch -- huh?!?
From: Ron Garret @ 2010-02-02 1:12 UTC (permalink / raw)
To: git
In-Reply-To: <7vk4uwmp95.fsf@alter.siamese.dyndns.org>
In article <7vk4uwmp95.fsf@alter.siamese.dyndns.org>,
Junio C Hamano <gitster@pobox.com> wrote:
> Ron Garret <ron1@flownet.com> writes:
>
> > The manual specifically contradicts you, so either you are wrong or the
> > manual is wrong.
>
> In case you haven't noticed, Pasky is one of the old timers and he knows a
> thing or two about the git's world model.
My intent was not to diss Pasky, it was just to point out a disconnect
between what he was saying and what the manual says. It's quite
possible that the manual is wrong or out of date or just misleading.
But it says what it says.
> And I do not see a contradiction in what the manual describes and "a
> branch is a named pointer to a commit" (although "named" can probably be
> omitted as "unnamed pointer" is not useful at the UI level).
But that's not what the manual says. The manual says, "When we need to
be precise, we will use the word "branch" to mean a line of
development..." Those are the first words in the section entitled
"Understanding history: What is a branch?" It certainly appears to the
untrained eye that that is intended to be the definition of a branch.
Maybe the manual just needs to be updated. "A named pointer to a
commit" is a useful definition, and a lot clearer than "a line of
development" (I don't even know what that means). I do think it's
important to keep "named" to distinguish them from, for example, SHA1
hashes which are (or at least can be) unnamed pointers to commits.
In fact, the whole issue of detached/attached HEAD comes down to whether
HEAD is a direct reference to a commit through its hash, or an indirect
reference to a commit through a named reference that it "drags along"
the next time a commit is, er, committed. :-)
BTW, my intent here is not to critique git's design, or to pump myself
up as some kind of an expert or to cut anybody down or anything like
that. I'm just trying to point out how what is written down can lead to
confusion for someone who doesn't know what's going on, and to make some
constructive suggestions on how the situation could be improved. That's
all.
rg
^ permalink raw reply
* Re: [PATCH 8/8 v6] gitweb: Add an option to force version match
From: Jakub Narebski @ 2010-02-02 1:35 UTC (permalink / raw)
To: J.H.; +Cc: git, John 'Warthog9' Hawley, Petr Baudis
In-Reply-To: <4B677971.2080100@eaglescrag.net>
On Mon, 1 Feb 2010, at 17:01:37 -0800, J.H. wrote:
> Starting to pop off the stack, and this came up first. A quick reading
> of this, I'd sign-off and agree to patches 1-7 completely.
>
> I'm still going to take issue that this being off by default is the
> wrong behavior and leaving this off by default more or less means that
> it will never get run and it becomes useless code. If this isn't on by
> default, it shouldn't be committed, as I can't think of a legitimate use
> case where an admin is going to turn this on.
Well, I don't think that mismatched git and gitweb version should be
serious problem in practice, unless they are seriously out of sync.
And in such situation (where either git is stale and gitweb updated,
or git updated and gitweb kept stale e.g. because it is heavily
customized with not ported changes) gitweb admin should turn this
feature on.
>
> I'd still argue this needs to be on by default to at least give admins
> the explicit warning that if they want to deviate they are taking their
> own risks, and that gitweb might not run as expected. Once the warning
> is disabled in a configuration file it's not like it's going to be
> re-enabled. People loading gitweb from their distro's package
> management will likely be in sync properly and will never see this.
> Those who are installing gitweb independent of their distro's package
> management will at least be warned of the risk, at least until better
> error reporting is done and in gitweb.
If you want to have it turned on by default (which is _incompatible_
change, and which was not announced enough, I think; it might mean
that gitweb can stop working after git or gitweb update), beside
changing commit message and gitweb/README (and of course definition of
$git_versions_must_match variable), you would have also update
explanation in die_error for version mismatch.
Current version, as requested by Petr 'Pasky' Baudis, explains how
to turn feature off if it was enabled. For this it needs to check
which config file is present, but we know at least that some config
file had to be used (beside possibility of hand-editing gitweb.cgi).
This is not the case if this feature is turned on by default: there
is possible that there is no gitweb config file, and all configuration
was done at build time. How to explain then how to turn this feature
off? What happens if both $GIWEB_CONFIG and $GITWEB_CONFIG_SYSTEM
are empty because of misconfiguration during build ($GITWEB_CONFIG
is set by default to gitweb_config.perl, and $GITWEB_CONFIG_SYSTEM
is set by default to /etc/gitweb.conf)? Which one to recommend if both
variables are set, but neither file exists?
The difficulty of explanation how to turn this feature off if it is
on by default was one of main reasons to not have it turned on by
default.
Side-note: Perhaps error is too strong a measure, and it would be better
to just issue warning somewhere instead?
>
> I've got a slightly modified version of this that re-enables it by
> default, it passes t9501 for me.
As it should, because gitweb-lib.sh was modified to explicitly turn off
this feature (see below), to allow testing gitweb without need to
recompile whole git, and to allow testing _not installed_ (source)
version of gitweb.
> > diff --git a/t/gitweb-lib.sh b/t/gitweb-lib.sh
> > index 5a734b1..66a3e2d 100755
> > --- a/t/gitweb-lib.sh
> > +++ b/t/gitweb-lib.sh
> > @@ -26,6 +26,7 @@ our \$projects_list = '';
> > our \$export_ok = '';
> > our \$strict_export = '';
> > our \$maxload = undef;
> > +our \$git_versions_must_match = 0;
> >
> > EOF
> >
--
Jakub Narebski
Poland
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox