* 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: Ron Garret @ 2010-01-29 22:12 UTC (permalink / raw)
To: git
In-Reply-To: <7vmxzwh906.fsf@alter.siamese.dyndns.org>
In article <7vmxzwh906.fsf@alter.siamese.dyndns.org>,
Junio C Hamano <gitster@pobox.com> wrote:
> 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 ."
Yes!!! That's it exactly!
rg
^ permalink raw reply
* [PATCH] Windows: a minimal pthread_cond_broadcast
From: Johannes Sixt @ 2010-01-29 22:16 UTC (permalink / raw)
To: Zoltán Füzesi; +Cc: git, msysGit Mailinglist
In-Reply-To: <201001292102.49105.j6t@kdbg.org>
[Cc msysgit list]
On Freitag, 29. Januar 2010, Johannes Sixt wrote:
> cond_broadcast is not that trivial.
... except when it can be tailor-made for a particular use-case.
What do people think about this?
I had implemented a full-blown pthread_cond_broadcast, taking ACE as
an example, but I had doubts about its correctness. Then I noticed that
we do not need a complete implementation anyway. So here we go...
--- 8< ---
From: Johannes Sixt <j6t@kdbg.org>
Subject: [PATCH] Windows: a minimal pthread_cond_broadcast
This is not an implementation, but more a fake of pthread_cond_broadcast.
It is sufficient for the only call site in builtin-grep.c that we have
at this time. It works because the threads that wake up due to this call
do not call pthread_cond_wait anymore and terminate.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
compat/win32/pthread.c | 10 ++++++++++
compat/win32/pthread.h | 4 +---
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/compat/win32/pthread.c b/compat/win32/pthread.c
index 631c0a4..7b5cac1 100644
--- a/compat/win32/pthread.c
+++ b/compat/win32/pthread.c
@@ -108,3 +108,13 @@ int pthread_cond_signal(pthread_cond_t *cond)
else
return 0;
}
+
+/*
+ * FIXME: This is a fake implementation that is tailored for the only
+ * user that we currently have.
+ */
+int pthread_cond_broadcast(pthread_cond_t *cond)
+{
+ ReleaseSemaphore(cond->sema, cond->waiters, NULL);
+ return 0;
+}
diff --git a/compat/win32/pthread.h b/compat/win32/pthread.h
index b8e1bcb..7c360d5 100644
--- a/compat/win32/pthread.h
+++ b/compat/win32/pthread.h
@@ -37,12 +37,10 @@ typedef struct {
} pthread_cond_t;
extern int pthread_cond_init(pthread_cond_t *cond, const void *unused);
-
extern int pthread_cond_destroy(pthread_cond_t *cond);
-
extern int pthread_cond_wait(pthread_cond_t *cond, CRITICAL_SECTION *mutex);
-
extern int pthread_cond_signal(pthread_cond_t *cond);
+extern int pthread_cond_broadcast(pthread_cond_t *cond);
/*
* Simple thread creation implementation using pthread API
--
1.6.6.264.ga6155
^ permalink raw reply related
* Re: Partially private repository?
From: Avery Pennarun @ 2010-01-29 22:10 UTC (permalink / raw)
To: Daed Lee; +Cc: git
In-Reply-To: <78d8a6b51001291401ib93976el25c03694d53aaced@mail.gmail.com>
On Fri, Jan 29, 2010 at 5:01 PM, Daed Lee <daed@thoughtsofcode.com> wrote:
> 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?
You should probably split your history into two pieces: the "before"
and "after" parts. To split out the "after" part, you could use
git-filter-branch
(http://www.kernel.org/pub/software/scm/git/docs/v1.6.0.6/git-filter-branch.html).
Then, in your private copy of the repo, you could reattach the
"before" part of the history using git grafts.
Have fun,
Avery
^ permalink raw reply
* Re: master^ is not a local branch -- huh?!?
From: Ron Garret @ 2010-01-29 22:18 UTC (permalink / raw)
To: git
In-Reply-To: <7veil8h8rk.fsf@alter.siamese.dyndns.org>
In article <7veil8h8rk.fsf@alter.siamese.dyndns.org>,
Junio C Hamano <gitster@pobox.com> wrote:
> 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.
s/complain/warn/
I'm just suggesting that maybe triggering the advanced feature ought not
to be such an easy thing to do by accident. It's certainly possible to
make that change. Reasonable people could disagree over whether this is
desirable, or whether it would be better to just add this to a FAQ
somewhere, or maybe even just leave this as a rite of passage.
Apparently I'm the first person to ever have this problem or it would
not have triggered so much discussion.
rg
^ permalink raw reply
* is there a way to reference the branch point?
From: layer @ 2010-01-29 22:29 UTC (permalink / raw)
To: git
If I make a branch `foo' off master, commit a bunch of times, is there
a way to reference the place on master from which I branched?
Thanks.
Kevin
^ permalink raw reply
* unable to run gc (or git repack -Adl )
From: Jon Nelson @ 2010-01-29 22:29 UTC (permalink / raw)
To: git
Using 1.6.4.2 on openSUSE 11.2 (x86_64).
I have a beefy repo (du of 14GB) that I can't seem to run 'gc' on.
After running for over 2 hours, this is what I get:
Counting objects: 267676, done.
Compressing objects: 100% (217424/217424), done.
fatal: Unable to create temporary file: Too many open files
error: failed to run repack
Ugh!
I have 3 GB of memory (and 1GB of swap).
When I strace the various processes, I see some things I don't understand:
1. I see the 'git-repack' shell process scanning for .keep files. I
don't have any. Is there a shortcut to this?
It's also hugely inefficient. In this case, the code to identify non
.keep packs takes *4 minutes, 45 seconds*, lots of disk I/O, and lots
of CPU (it pegs one CPU at 100% for the entire duration). With a wee
bit of awk, I have reduced that to 2.3 seconds with VASTLY reduced I/O
and CPU requirements. Patch attached.
2. When git-pack-objects is being run, around the time it's 85% done
"compressing" it's very very very slow. Like, 2-5 objects every
second. The largest object in the repo is about 1MB.
3. When git pack objects is running and counting up the number of
objects, it is stat'ing files that aren't in the working directly, and
should not be, according to the index. If I switch the repo to be a
"bare" repository, then it doesn't do that, however, why is it doing
that in the first place?
4. Should git-pack-objects be reading the pack.idx files for counting
objects instead of the .pack files themselves?
5. There is no 5
6. Should git-pack-objects be closing .pack files after opening them?
I have 6559 .pack files.
7. Ultimately, how do I get "git gc" to work on this repo?
diff --git a/git-repack.sh b/git-repack.sh
index 1eb3bca..4358f96 100755
--- a/git-repack.sh
+++ b/git-repack.sh
@@ -62,15 +62,7 @@ case ",$all_into_one," in
,t,)
args= existing=
if [ -d "$PACKDIR" ]; then
- for e in `cd "$PACKDIR" && find . -type f -name '*.pack' \
- | sed -e 's/^\.\///' -e 's/\.pack$//'`
- do
- if [ -e "$PACKDIR/$e.keep" ]; then
- : keep
- else
- existing="$existing $e"
- fi
- done
+ existing=$( find . -type f -name '*.pack' -o -name
'*.pack.keep' | sed -e 's/^\.\///' | sort | awk '{ if ($0 ~ /\.keep$/)
{ N=substr($0, 0, length($0)-5); K[N]=0; } else { K[$0]=1; } } END {
for (k in K) { if (K[k] == 1) { printf "%s ", k; } } } ' )
if test -n "$existing" -a -n "$unpack_unreachable" -a \
-n "$remove_redundant"
then
--
Jon
^ permalink raw reply related
* Re: master^ is not a local branch -- huh?!?
From: Octavio Alvarez @ 2010-01-29 22:32 UTC (permalink / raw)
To: Ron Garret, git
In-Reply-To: <ron1-1F1799.13340029012010@news.gmane.org>
On Fri, 29 Jan 2010 13:34:01 -0800, Ron Garret <ron1@flownet.com> wrote:
> 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:
>>
>> 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.
I see. You somehow imply that "git checkout commit-id" overlaps with
"git reset --hard commit-id".
Even assuming the behavior was not documented in man git-checkout, the
second example looks useless. What is your use case? What would you do
after having all the files in the tree switched to another commit,
without actually updating HEAD to the commit, other than git reset --hard
again or git revert?
^ permalink raw reply
* Re: master^ is not a local branch -- huh?!?
From: Nicolas Pitre @ 2010-01-29 22:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sverre Rabbelier, Git List, Ron1, Jacob Helwig
In-Reply-To: <7viqakh8ty.fsf@alter.siamese.dyndns.org>
On Fri, 29 Jan 2010, Junio C Hamano wrote:
> 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.
OK. That is probably sensible.
I don't think any improvement on the detached head message should
presume on this though.
And it might be a good idea to say explicitly that what happened is the
creation of a detached HEAD, like in:
diff --git a/builtin-checkout.c b/builtin-checkout.c
index 5277817..c0a44d7 100644
--- a/builtin-checkout.c
+++ b/builtin-checkout.c
@@ -523,7 +523,10 @@ 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: '%s' isn't a local branch head: creating a detached HEAD\n"
+ "If 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);
}
}
(string split onto multiple lines for easier source reading)
I think this is important to 1) mention the notion of a branch _head_,
and 2) mention "detached HEAD" explicitly for people to be directed to
appropriate documentation. So with this change you know exactly what
happened and why.
Nicolas
^ permalink raw reply related
* Re: is there a way to reference the branch point?
From: Sverre Rabbelier @ 2010-01-29 22:35 UTC (permalink / raw)
To: layer; +Cc: git
In-Reply-To: <18219.1264804157@relay.known.net>
Heya,
On Fri, Jan 29, 2010 at 23:29, layer <layer@known.net> wrote:
> If I make a branch `foo' off master, commit a bunch of times, is there
> a way to reference the place on master from which I branched?
Depends, if you make a new branch from master, you can use 'git merge-base', so:
$ # on master
$ git checkout -b foo-topic-branch
$ # work work
$ git commit
$ # work work
$ git commit
Now you want to know where you branches off from master:
$ git merge-base foo-topic-branch master
That will show you the commit you branches off from, even if master
has grown new commits since then.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* [PATCH] run-command.c: fix build warnings on Ubuntu
From: Michael Wookey @ 2010-01-29 22:38 UTC (permalink / raw)
To: Git Mailing List
Building git on Ubuntu 9.10 warns that the return value of write(2)
isn't checked. These warnings were introduced in commits:
2b541bf8 ("start_command: detect execvp failures early")
a5487ddf ("start_command: report child process setup errors to the
parent's stderr")
GCC details:
$ gcc --version
gcc (Ubuntu 4.4.1-4ubuntu9) 4.4.1
Silence the warnings by reading (but not making use of) the return value
of write(2).
Signed-off-by: Michael Wookey <michaelwookey@gmail.com>
---
Although this will fix the build warnings, I am unsure if there is a
better way to achieve the same result. Using "(void)write(...)" still
gives warnings and I am unaware of any annotations that will silence
gcc.
run-command.c | 10 ++++++----
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/run-command.c b/run-command.c
index 2feb493..3206d61 100644
--- a/run-command.c
+++ b/run-command.c
@@ -67,19 +67,21 @@ static int child_notifier = -1;
static void notify_parent(void)
{
- write(child_notifier, "", 1);
+ ssize_t unused;
+ unused = write(child_notifier, "", 1);
}
static NORETURN void die_child(const char *err, va_list params)
{
char msg[4096];
+ ssize_t unused;
int len = vsnprintf(msg, sizeof(msg), err, params);
if (len > sizeof(msg))
len = sizeof(msg);
- write(child_err, "fatal: ", 7);
- write(child_err, msg, len);
- write(child_err, "\n", 1);
+ unused = write(child_err, "fatal: ", 7);
+ unused = write(child_err, msg, len);
+ unused = write(child_err, "\n", 1);
exit(128);
}
--
1.7.0.rc0.48.gdace5
^ permalink raw reply related
* Re: master^ is not a local branch -- huh?!?
From: Junio C Hamano @ 2010-01-29 22:39 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Junio C Hamano, Sverre Rabbelier, Git List, Ron1, Jacob Helwig
In-Reply-To: <alpine.LFD.2.00.1001291716070.1681@xanadu.home>
Nicolas Pitre <nico@fluxnic.net> writes:
> On Fri, 29 Jan 2010, Junio C Hamano wrote:
>
>> 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.
>
> OK. That is probably sensible.
>
> I don't think any improvement on the detached head message should
> presume on this though.
>
> And it might be a good idea to say explicitly that what happened is the
> creation of a detached HEAD, like in:
Any comment on my previous rewording patch ($gmane/138369)?
"Note: '%s' isn't a local branch head: creating a detached HEAD\n"
"If 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);
A major difference I think is that I avoided a jargon (detached HEAD), and
chose not to say why the input was interpreted as a request to switch to
that state.
Oh, of course, I also added advice.detachedHEAD to squelch it ;-)
^ permalink raw reply
* Re: master^ is not a local branch -- huh?!?
From: Jacob Helwig @ 2010-01-29 22:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, Sverre Rabbelier, Git List, Ron1
In-Reply-To: <7vaavwh6yh.fsf@alter.siamese.dyndns.org>
On Fri, Jan 29, 2010 at 14:39, Junio C Hamano <gitster@pobox.com> wrote:
> Any comment on my previous rewording patch ($gmane/138369)?
>
> "Note: '%s' isn't a local branch head: creating a detached HEAD\n"
> "If 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);
>
> A major difference I think is that I avoided a jargon (detached HEAD), and
> chose not to say why the input was interpreted as a request to switch to
> that state.
>
> Oh, of course, I also added advice.detachedHEAD to squelch it ;-)
>
For what it's worth, I'm +1 for this. Especially the ability to squelch it.
^ permalink raw reply
* Re: master^ is not a local branch -- huh?!?
From: Ron Garret @ 2010-01-29 22:47 UTC (permalink / raw)
To: git
In-Reply-To: <op.u7bfjni44oyyg1@alvarezp-ws>
In article <op.u7bfjni44oyyg1@alvarezp-ws>,
"Octavio Alvarez" <alvarezp@alvarezp.ods.org> wrote:
> On Fri, 29 Jan 2010 13:34:01 -0800, Ron Garret <ron1@flownet.com> wrote:
>
> > 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:
> >>
> >> 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.
>
> I see. You somehow imply that "git checkout commit-id" overlaps with
> "git reset --hard commit-id".
I'm not intentionally implying that. I don't think git reset --hard
does what I want either (but I could be wrong about that).
> Even assuming the behavior was not documented in man git-checkout, the
> second example looks useless. What is your use case? What would you do
> after having all the files in the tree switched to another commit,
> without actually updating HEAD to the commit, other than git reset --hard
> again or git revert?
My actual use case is very complicated, but here's a simplified version:
Suppose I'm using git as a back-end for a wiki. I want to look at the
state of the entire wiki as it was in some point in the past, and I also
want to be able to look at the diffs between individual pages as they
were then and as they are now. The most straightforward way I can think
of to do that is to simply copy an old commit into my working tree
without changing anything else. Then I can look at the old version by
simply looking at the files, and I can get the diffs by simply doing a
git diff.
If I do a git reset --hard then I get the old version, but I lose my
HEAD pointer so that git diff doesn't give me what I want any more.
BTW, it turns out that git checkout [commit] . doesn't do the right
thing either. Apparently, it still updates my index, so git diff still
doesn't do the right thing.
rg
^ permalink raw reply
* Re: [PATCH v2] fast-import: Stream very large blobs directly to pack
From: A Large Angry SCM @ 2010-01-29 23:02 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20100129183024.GA22101@spearce.org>
Shawn O. Pearce wrote:
...
> Implemented as core.bigFileThreshold in this patch... but I didn't
> document it...
Bad dog! No biscuit!
^ permalink raw reply
* Re: master^ is not a local branch -- huh?!?
From: Octavio Alvarez @ 2010-01-29 23:05 UTC (permalink / raw)
To: Ron Garret, git
In-Reply-To: <ron1-0EE62E.14474929012010@news.gmane.org>
On Fri, 29 Jan 2010 14:47:49 -0800, Ron Garret <ron1@flownet.com> wrote:
>
> My actual use case is very complicated, but here's a simplified version:
>
> Suppose I'm using git as a back-end for a wiki. I want to look at the
> state of the entire wiki as it was in some point in the past,
mkdir new_dir; git archive --format=tar tree-ish | tar -C new_dir -x
Of course, this is slower than just checking out the files that differ,
I agree.
> and I also
> want to be able to look at the diffs between individual pages as they
> were then and as they are now.
git diff commit-ish1 commit-ish2 file1 file2 ...
Or you could just clone it and compare whatever you want there and just
erase when done. This would allow you to do "git pull" from the origin.
> If I do a git reset --hard then I get the old version, but I lose my
> HEAD pointer so that git diff doesn't give me what I want any more.
You could tag the current version before resetting and then issue
git reset --hard the_tag, but I guess you would run into race conditions:
someone updates the wiki while the HEAD is in another commit.
Hope it helps. :-)
^ permalink raw reply
* Re: master^ is not a local branch -- huh?!?
From: Junio C Hamano @ 2010-01-29 23:12 UTC (permalink / raw)
To: Ron Garret; +Cc: git
In-Reply-To: <ron1-0EE62E.14474929012010@news.gmane.org>
Ron Garret <ron1@flownet.com> writes:
> My actual use case is very complicated, but here's a simplified version:
>
> Suppose I'm using git as a back-end for a wiki. I want to look at the
> state of the entire wiki as it was in some point in the past, and I also
> want to be able to look at the diffs between individual pages as they
> were then and as they are now.
Don't think you are so special ;-) "git checkout $that_old_commit" was
invented _exactly_ for that use case. You can look around from that
state, and when you are done sightseeing, you can come back by doing a
"git checkout master" (or whichever branch you want to be on).
You don't necessarily have to check out an old state if the only thing
you are interested in is to review how the contents changed over time.
Use "git log -p" (from the current tip) for that.
If you chose to have an old checkout and then traverse the changes over
time leading to the current tip, you would say "git log -p ..master"
instead.
^ permalink raw reply
* Re: master^ is not a local branch -- huh?!?
From: A Large Angry SCM @ 2010-01-29 23:16 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Nicolas Pitre, Junio C Hamano, Git List, Ron1, Jacob Helwig
In-Reply-To: <fabb9a1e1001291332w1d161f8at58aa6fe6908bd77f@mail.gmail.com>
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'. 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?
>
[I'm still catching up on this thread]
What we call 'Detached head' is _the_ normal way ti use git for quite a
number of users. And given the current UI, it's not really advanced.
^ permalink raw reply
* Re: master^ is not a local branch -- huh?!?
From: Ron Garret @ 2010-01-29 23:30 UTC (permalink / raw)
To: git
In-Reply-To: <7vk4v0fqts.fsf@alter.siamese.dyndns.org>
In article <7vk4v0fqts.fsf@alter.siamese.dyndns.org>,
Junio C Hamano <gitster@pobox.com> wrote:
> Ron Garret <ron1@flownet.com> writes:
>
> > My actual use case is very complicated, but here's a simplified version:
> >
> > Suppose I'm using git as a back-end for a wiki. I want to look at the
> > state of the entire wiki as it was in some point in the past, and I also
> > want to be able to look at the diffs between individual pages as they
> > were then and as they are now.
>
> Don't think you are so special ;-)
Never. :-)
> "git checkout $that_old_commit" was
> invented _exactly_ for that use case. You can look around from that
> state, and when you are done sightseeing, you can come back by doing a
> "git checkout master" (or whichever branch you want to be on).
Yes, that's what I would have expected. Except that it not only updates
my working tree, it updates my head also, so git diff doesn't give me
the diffs that I want. (This makes sense for the usual use case.)
> You don't necessarily have to check out an old state if the only thing
> you are interested in is to review how the contents changed over time.
> Use "git log -p" (from the current tip) for that.
>
> If you chose to have an old checkout and then traverse the changes over
> time leading to the current tip, you would say "git log -p ..master"
> instead.
There's also this:
git rev-list HEAD -- [filename]
git ls-tree [some-hash-from-the-list-above]
Then for each line in the result:
git cat-file blob [hash] > [filename]
which seems like a horrible hack, but actually does what I want.
rg
^ permalink raw reply
* Re: master^ is not a local branch -- huh?!?
From: Julian Phillips @ 2010-01-29 23:28 UTC (permalink / raw)
To: Ron Garret; +Cc: git
In-Reply-To: <ron1-0EE62E.14474929012010@news.gmane.org>
On Fri, 29 Jan 2010 14:47:49 -0800, Ron Garret <ron1@flownet.com> wrote:
> My actual use case is very complicated, but here's a simplified version:
>
> Suppose I'm using git as a back-end for a wiki. I want to look at the
> state of the entire wiki as it was in some point in the past, and I also
> want to be able to look at the diffs between individual pages as they
> were then and as they are now. The most straightforward way I can think
> of to do that is to simply copy an old commit into my working tree
> without changing anything else. Then I can look at the old version by
> simply looking at the files, and I can get the diffs by simply doing a
> git diff.
>
> If I do a git reset --hard then I get the old version, but I lose my
> HEAD pointer so that git diff doesn't give me what I want any more.
>
> BTW, it turns out that git checkout [commit] . doesn't do the right
> thing either. Apparently, it still updates my index, so git diff still
> doesn't do the right thing.
If I understand what you want correctly, then:
git diff --cached -R [path]
should be the appropriate command after the "git checkout <commit> .".
--
Julian
^ permalink raw reply
* Re: master^ is not a local branch -- huh?!?
From: Nicolas Pitre @ 2010-01-29 23:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sverre Rabbelier, Git List, Ron1, Jacob Helwig
In-Reply-To: <7vaavwh6yh.fsf@alter.siamese.dyndns.org>
On Fri, 29 Jan 2010, Junio C Hamano wrote:
> Any comment on my previous rewording patch ($gmane/138369)?
A bit too verbose (even if it can be configured out) and frightening I'd
say.
> "Note: '%s' isn't a local branch head: creating a detached HEAD\n"
> "If 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);
>
> A major difference I think is that I avoided a jargon (detached HEAD), and
> chose not to say why the input was interpreted as a request to switch to
> that state.
To the contrary, I think it is about time we use proper Git jargon.
Otherwise how can we expect people to relate to the documentation where
that jargon is indeed used? Even on this very mailing list we refer to
that state as a "detached HEAD". And Google gives precisely the right
info with "detached HEAD" while any other verbiage might not.
And just saying that "you're not on any branch anymore" is still leaving
the user wondering why. At least with the "isn't a local branch head"
the user has 2 clues: it has to be a _local_ branch and a branch _head_
not to create a detached HEAD. So I still prefer the above rewording.
> Oh, of course, I also added advice.detachedHEAD to squelch it ;-)
That is indeed an excellent idea.
Nicolas
^ permalink raw reply
* [PATCH] Implement pthread_cond_broadcast on Windows
From: Johannes Sixt @ 2010-01-29 23:54 UTC (permalink / raw)
To: Junio C Hamano
Cc: Zoltán Füzesi, git, msysGit Mailinglist, Dmitry Potapov,
Andrzej K. Haczewski, Erik Faye-Lund
In-Reply-To: <201001292316.03858.j6t@kdbg.org>
See http://www.cse.wustl.edu/~schmidt/win32-cv-1.html, section "The
SignalObjectAndWait solution". But note that this implementation does not
use SignalObjectAndWait (which is needed to achieve fairness, but we do
not need fairness).
Note that our implementations of pthread_cond_broadcast and
pthread_cond_signal require that they are invoked with the mutex held that
is used in the pthread_cond_wait calls.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
Junio,
please queue this patch for 1.7.0-rc1 even though it has not undergone
a lot of review - the result is better than a git that does not even
build on Windows.
I had another look at this complete implementation of p_c_b and am now
convinced that it is correct, but an extra set of eye-balls is always
appreciated. I've Cc'd people who had shown interest in pthreads on
Windows in the past.
-- Hannes
compat/win32/pthread.c | 100 ++++++++++++++++++++++++++++++++++++++++++-----
compat/win32/pthread.h | 9 ++--
2 files changed, 94 insertions(+), 15 deletions(-)
diff --git a/compat/win32/pthread.c b/compat/win32/pthread.c
index 631c0a4..e592084 100644
--- a/compat/win32/pthread.c
+++ b/compat/win32/pthread.c
@@ -52,24 +52,38 @@ int win32_pthread_join(pthread_t *thread, void **value_ptr)
int pthread_cond_init(pthread_cond_t *cond, const void *unused)
{
cond->waiters = 0;
+ cond->was_broadcast = 0;
+ InitializeCriticalSection(&cond->waiters_lock);
cond->sema = CreateSemaphore(NULL, 0, LONG_MAX, NULL);
if (!cond->sema)
die("CreateSemaphore() failed");
+
+ cond->continue_broadcast = CreateEvent(NULL, /* security */
+ FALSE, /* auto-reset */
+ FALSE, /* not signaled */
+ NULL); /* name */
+ if (!cond->continue_broadcast)
+ die("CreateEvent() failed");
+
return 0;
}
int pthread_cond_destroy(pthread_cond_t *cond)
{
CloseHandle(cond->sema);
- cond->sema = NULL;
-
+ CloseHandle(cond->continue_broadcast);
+ DeleteCriticalSection(&cond->waiters_lock);
return 0;
}
int pthread_cond_wait(pthread_cond_t *cond, CRITICAL_SECTION *mutex)
{
- InterlockedIncrement(&cond->waiters);
+ int last_waiter;
+
+ EnterCriticalSection(&cond->waiters_lock);
+ cond->waiters++;
+ LeaveCriticalSection(&cond->waiters_lock);
/*
* Unlock external mutex and wait for signal.
@@ -82,22 +96,52 @@ int pthread_cond_wait(pthread_cond_t *cond, CRITICAL_SECTION *mutex)
/* let's wait - ignore return value */
WaitForSingleObject(cond->sema, INFINITE);
- /* we're done waiting, so make sure we decrease waiters count */
- InterlockedDecrement(&cond->waiters);
-
+ /*
+ * Decrease waiters count. If we are the last waiter, then we must
+ * notify the broadcasting thread that it can continue.
+ * But if we continued due to cond_signal, we do not have to do that
+ * because the signaling thread knows that only one waiter continued.
+ */
+ EnterCriticalSection(&cond->waiters_lock);
+ cond->waiters--;
+ last_waiter = cond->was_broadcast && cond->waiters == 0;
+ LeaveCriticalSection(&cond->waiters_lock);
+
+ if (last_waiter) {
+ /*
+ * cond_broadcast was issued while mutex was held. This means
+ * that all other waiters have continued, but are contending
+ * for the mutex at the end of this function because the
+ * broadcasting thread did not leave cond_broadcast, yet.
+ * (This is so that it can be sure that each waiter has
+ * consumed exactly one slice of the semaphor.)
+ * The last waiter must tell the broadcasting thread that it
+ * can go on.
+ */
+ SetEvent(cond->continue_broadcast);
+ /*
+ * Now we go on to contend with all other waiters for
+ * the mutex. Auf in den Kampf!
+ */
+ }
/* lock external mutex again */
EnterCriticalSection(mutex);
return 0;
}
+/*
+ * IMPORTANT: This implementation requires that pthread_cond_signal
+ * is called while the mutex is held that is used in the corresponding
+ * pthread_cond_wait calls!
+ */
int pthread_cond_signal(pthread_cond_t *cond)
{
- /*
- * Access to waiters count is atomic; see "Interlocked Variable Access"
- * http://msdn.microsoft.com/en-us/library/ms684122(VS.85).aspx
- */
- int have_waiters = cond->waiters > 0;
+ int have_waiters;
+
+ EnterCriticalSection(&cond->waiters_lock);
+ have_waiters = cond->waiters > 0;
+ LeaveCriticalSection(&cond->waiters_lock);
/*
* Signal only when there are waiters
@@ -108,3 +152,37 @@ int pthread_cond_signal(pthread_cond_t *cond)
else
return 0;
}
+
+/*
+ * DOUBLY IMPORTANT: This implementation requires that pthread_cond_broadcast
+ * is called while the mutex is held that is used in the corresponding
+ * pthread_cond_wait calls!
+ */
+int pthread_cond_broadcast(pthread_cond_t *cond)
+{
+ EnterCriticalSection(&cond->waiters_lock);
+
+ if ((cond->was_broadcast = cond->waiters > 0)) {
+ /* wake up all waiters */
+ ReleaseSemaphore(cond->sema, cond->waiters, NULL);
+ LeaveCriticalSection(&cond->waiters_lock);
+ /*
+ * At this point all waiters continue. Each one takes its
+ * slice of the semaphor. Now it's our turn to wait: Since
+ * the external mutex is held, no thread can leave cond_wait,
+ * yet. For this reason, we can be sure that no thread gets
+ * a chance to eat *more* than one slice. OTOH, it means
+ * that the last waiter must send us a wake-up.
+ */
+ WaitForSingleObject(cond->continue_broadcast, INFINITE);
+ /*
+ * Since the external mutex is held, no thread can enter
+ * cond_wait, and, hence, it is safe to reset this flag
+ * without cond->waiters_lock held.
+ */
+ cond->was_broadcast = 0;
+ } else {
+ LeaveCriticalSection(&cond->waiters_lock);
+ }
+ return 0;
+}
diff --git a/compat/win32/pthread.h b/compat/win32/pthread.h
index b8e1bcb..c72f100 100644
--- a/compat/win32/pthread.h
+++ b/compat/win32/pthread.h
@@ -32,17 +32,18 @@
* See also: http://www.cse.wustl.edu/~schmidt/win32-cv-1.html
*/
typedef struct {
- volatile LONG waiters;
+ LONG waiters;
+ int was_broadcast;
+ CRITICAL_SECTION waiters_lock;
HANDLE sema;
+ HANDLE continue_broadcast;
} pthread_cond_t;
extern int pthread_cond_init(pthread_cond_t *cond, const void *unused);
-
extern int pthread_cond_destroy(pthread_cond_t *cond);
-
extern int pthread_cond_wait(pthread_cond_t *cond, CRITICAL_SECTION *mutex);
-
extern int pthread_cond_signal(pthread_cond_t *cond);
+extern int pthread_cond_broadcast(pthread_cond_t *cond);
/*
* Simple thread creation implementation using pthread API
--
1.6.6.264.ga6155
^ permalink raw reply related
* Re: master^ is not a local branch -- huh?!?
From: Junio C Hamano @ 2010-01-30 0:14 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Sverre Rabbelier, Git List, Ron1, Jacob Helwig
In-Reply-To: <alpine.LFD.2.00.1001291833580.1681@xanadu.home>
Nicolas Pitre <nico@fluxnic.net> writes:
> To the contrary, I think it is about time we use proper Git jargon.
> Otherwise how can we expect people to relate to the documentation where
> that jargon is indeed used? Even on this very mailing list we refer to
> that state as a "detached HEAD". And Google gives precisely the right
> info with "detached HEAD" while any other verbiage might not.
>
> And just saying that "you're not on any branch anymore" is still leaving
> the user wondering why. At least with the "isn't a local branch head"
> the user has 2 clues: it has to be a _local_ branch and a branch _head_
> not to create a detached HEAD. So I still prefer the above rewording.
I can buy that argument, except for three minor points:
- I think we also should give information necessary to judge if the user
wants to stay in the detached HEAD state. IOW, "Why am I getting an
insn to create a new branch? What is wrong with this detached HEAD
state? Why would I want a local branch?" are still not explained with
the updated message.
- Do we "create" a detached HEAD, or are we just "detaching HEAD"?
- Running "checkout -b" now will create a new branch from that checkout,
but doing so _later_ won't necessarily do so from that _checkout_.
So how about doing this (changes to advice.[ch] are omitted)?
diff --git a/builtin-checkout.c b/builtin-checkout.c
index 5277817..41fc00a 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: '%s' isn't a local branch head.\n\n"
+"HEAD is detached at that commit. You can look around, even make changes\n"
+"and record them in new commits, but any new commit you make from now on\n"
+"will be lost when you check out another branch.\n"
+"If you want to create a new branch from this state, 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\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-30 0:14 UTC (permalink / raw)
To: git
In-Reply-To: <bd7fb2a884e55e176eea3002fd0c68dd@212.159.54.234>
In article <bd7fb2a884e55e176eea3002fd0c68dd@212.159.54.234>,
Julian Phillips <julian@quantumfyre.co.uk> wrote:
> On Fri, 29 Jan 2010 14:47:49 -0800, Ron Garret <ron1@flownet.com> wrote:
> > My actual use case is very complicated, but here's a simplified version:
> >
> > Suppose I'm using git as a back-end for a wiki. I want to look at the
> > state of the entire wiki as it was in some point in the past, and I also
>
> > want to be able to look at the diffs between individual pages as they
> > were then and as they are now. The most straightforward way I can think
>
> > of to do that is to simply copy an old commit into my working tree
> > without changing anything else. Then I can look at the old version by
> > simply looking at the files, and I can get the diffs by simply doing a
> > git diff.
> >
> > If I do a git reset --hard then I get the old version, but I lose my
> > HEAD pointer so that git diff doesn't give me what I want any more.
> >
> > BTW, it turns out that git checkout [commit] . doesn't do the right
> > thing either. Apparently, it still updates my index, so git diff still
> > doesn't do the right thing.
>
> If I understand what you want correctly, then:
>
> git diff --cached -R [path]
>
> should be the appropriate command after the "git checkout <commit> .".
Yep, that works. Alternatively, is there a way to clear the index?
Seems like that would be better.
rg
^ permalink raw reply
* Re: master^ is not a local branch -- huh?!?
From: Sverre Rabbelier @ 2010-01-30 0:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, Git List, Ron1, Jacob Helwig
In-Reply-To: <7vy6jgcutb.fsf@alter.siamese.dyndns.org>
Heya,
On Sat, Jan 30, 2010 at 01:14, Junio C Hamano <gitster@pobox.com> wrote:
> +"If you want to create a new branch from this state, you may do so\n"
> +"(now or later) by using -b with the checkout command again.
I think the "this state" needs to be changed, it currently suggests
what you mention earlier in you reply, that it's about the current
state, even if you make commits on top of that. Maybe something in the
spirit of "If you want to create a new branch from ?? where you are at
the moment you follow these instructions ??".
--
Cheers,
Sverre Rabbelier
^ 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