* Re: git-rm -n leaves .git/index.lock if not allowed to finish
From: Junio C Hamano @ 2008-12-19 1:31 UTC (permalink / raw)
To: Miklos Vajna; +Cc: jidanni, git
In-Reply-To: <7v4p11f18d.fsf@gitster.siamese.dyndns.org>
Subject: [PATCH] Make sure lockfiles are unlocked when dying on SIGPIPE
We cleaned up lockfiles upon receiving the usual suspects HUP, TERM, QUIT
but a wicked user could kill us of asphyxiation by piping our output to a
pipe that does not read. Protect ourselves by catching SIGPIPE and clean
up the lockfiles as well in such a case.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
lockfile.c | 1 +
t/t3600-rm.sh | 17 +++++++++++++++++
2 files changed, 18 insertions(+), 0 deletions(-)
diff --git c/lockfile.c w/lockfile.c
index 6d75608..8589155 100644
--- c/lockfile.c
+++ w/lockfile.c
@@ -140,6 +140,7 @@ static int lock_file(struct lock_file *lk, const char *path, int flags)
signal(SIGHUP, remove_lock_file_on_signal);
signal(SIGTERM, remove_lock_file_on_signal);
signal(SIGQUIT, remove_lock_file_on_signal);
+ signal(SIGPIPE, remove_lock_file_on_signal);
atexit(remove_lock_file);
}
lk->owner = getpid();
diff --git c/t/t3600-rm.sh w/t/t3600-rm.sh
index b7d46e5..95542e9 100755
--- c/t/t3600-rm.sh
+++ w/t/t3600-rm.sh
@@ -251,4 +251,21 @@ test_expect_success 'refresh index before checking if it is up-to-date' '
'
+test_expect_success 'choking "git rm" should not let it die with cruft' '
+ git reset -q --hard &&
+ H=0000000000000000000000000000000000000000 &&
+ i=0 &&
+ while test $i -lt 12000
+ do
+ echo "100644 $H 0 some-file-$i"
+ i=$(( $i + 1 ))
+ done | git update-index --index-info &&
+ git rm -n "some-file-*" | :;
+ test -f .git/index.lock
+ status=$?
+ rm -f .git/index.lock
+ git reset -q --hard
+ test "$status" != 0
+'
+
test_done
^ permalink raw reply related
* Re: Odd merge behaviour involving reverts
From: Boyd Stephen Smith Jr. @ 2008-12-19 1:30 UTC (permalink / raw)
To: Alan; +Cc: git
In-Reply-To: <1229642734.5770.25.camel@rotwang.fnordora.org>
[-- Attachment #1: Type: text/plain, Size: 944 bytes --]
On Thursday 2008 December 18 17:25:34 Alan wrote:
> Here is my situation...
>
> I have a master branch. We have a branch off of that that some
> developers are doing work on. They claim it is ready. We merge it into
> the master branch. It breaks something so we revert the merge. They
> make changes to the code. they get it to a point where they say it is
> ok and we merge again.
>
> What am i doing wrong here?
Don't do tests on the master branch. Or at least, do as little as possible. Also, try not to revert merges. Depending on your workflow and team synamics it might be easier to rewrite history than wrangle reverts of a merge commit.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Simplified GIT usage guide
From: Paul E. McKenney @ 2008-12-19 1:27 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, David Howells, torvalds, git, linux-kernel
In-Reply-To: <7vabatf1pg.fsf@gitster.siamese.dyndns.org>
On Thu, Dec 18, 2008 at 04:28:11PM -0800, Junio C Hamano wrote:
> "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> writes:
>
> > On Fri, Dec 12, 2008 at 07:57:38PM +0100, Johannes Schindelin wrote:
> > ...
> >> I am sure we want to have something like that in git.git.
> >
> > So am I. Except that I am not being sarcastic. ;-)
>
> Hmm, but we seem to already have too many intro-to-git documents in tree.
> Perhaps good points in the document can be used to augment or replace
> parts of existing documents? For example, which part of the new
> documentation would have helped you avoid the pain you mentioned below...
I would be OK with it being in linux-2.6.git rather than git.git,
if that helps. Certainly there seems to be room for a description
of how to use git within the Linux community.
> > In particular, David's guide was quite helpful to me. It would have been
> > even more helpful had it existed when I first tried (unsuccessfully)
> > to use GIT. In particular, GIT's requirement that I tell it about new
> > versions of existing files (either with "git add" or "git commit -a")
> > was extremely counter-intuitive, and caused me no end of pain.
>
> ... and which part of the existing user manual or tutorial should have
> talked about it to help you?
The part that describes the differences between git and traditional
source-code-control packages. A few examples:
o Having to add files that are already there when changing them.
"Why do I need to add it? Can't git see that it is -already-
-there-???" ;-)
The key point is that traditional source-code has a file as a
first-class concept. Not git, which instead has a particular
revision of a file as the front-and-center first-class object.
Simply saying this is insufficient, as both git and (say) RCS
track both files and revisions to files. If you do simply state
this, the RCS guy will think he understands you, but he won't
have a clue.
o The fact that git's log changes depending on what branch
you are on is quite confusing to those of us who are used
to history being invariant. I am learning to do "git branch -l"
to see where I have been in my own git trees. No doubt there
is some way to dump out the relationship between the various
branches and some convention for "the current revision" for
the upstream git tree, but I have not found it yet.
Not that I have looked all that hard. The Linux kernel has
a nice linear series of version tags that tell me what I need.
But that is only because I work on stuff that is out of the
quickly changing mainstream. My own projects I still remember,
and keep textfiles listing what each branch is intended for.
o The fact that you can put a git archive into a state so that
"git remote update" changes the archive, but doesn't change
your view, nor any obvious-to-the-newbie attribute of the view.
The only way I know to get out of this is to carefully record
the new SHA hash that "git remote update" prints, and then do a
"git checkout" on that SHA hash. Given a quiescent archive,
how do I find the points of interest? For -tip, I can usually
check out "tip/core/rcu" and get where I need to go, but I am
quite unclear on navigation through a git archive. For one
thing, git will sometimes interpret "tip/core/rcu" as a path
name rather than as a navigation point (or whatever the heck
it really is).
o I need to work with multiple views of the same git archive.
Doing "git checkout"s back and forth within a single archive
does not do what I need. I have been experimenting with various
"git clone" archives and usually been getting my fingers burned
in various ways. In one case, I got a second archive, but
all the branches had disappeared. Why didn't they come across,
and what do I need to do to see them? remote/whatever, perhaps?
Dave's example might not be exactly what a git expert would
suggest, but at least it is an easy to follow procedure for
doing what I need to do.
o If you don't set up branches correctly, pulling in changes
from a remote copy of your archive will undo your recent changes
in your local archive. Fortunately, I was a bit paranoid by the
time I tried this, so noticed it while I could still easily
revert it.
o Troubleshooting guide. There is some of this in the various
"git reset --ripcord" options, but it will be necessary to
learn the mistakes that dinosaurs such as myself tend to make
with git, and describe how to detect and fix them. In contrast,
the existing troubleshooting guides seem designed for someone
for whom git is the only source-code control system they have
known.
> > But my experience is that git is at best an acquired taste for those of
> > us who grew up with traditional source-code control systems. Such
> > people will benefit greatly from a git-haters guide,...
>
> "Acquired taste" is a much nicer and more diplomatic way to say the same
> thing as what Linus often refers as "unlearning the braindamage inflicted
> by years of using CVS." ;-)
Heh. From my viewpoint, CVS is a very recent innovation. So I am sure
that you meant to write "unlearning the braindamage inflicted by years
of using RCS". ;-)
Heck, my first source-code-control system was a cabinet full of punched
cards. No joke. Another project used a whiteboard -- you wrote down the
names of the files that you were modifying in order to avoid conflicts.
So from my viewpoint, even RCS is a fairly recent innovation. ;-)
> > ..., and git's user
> > population will grow as a result.
>
> I do not think it constitutes any basis for judging the merit of having
> the document in git.git tree. The world domination is not our goal, but
> it may come as a mere side effect of being the best in the business.
Not if almost all of the people who grew up with old technology choke
on git the first time they come across it. I am here to tell you
that had I not been forced to use git in my work on the Linux kernel,
I would not have given it a second look. My first several experiences
with it were -extremely- frustrating. Not necessarily due to bugs
in git (though I might have been running into those, for all I know),
but because it invalidates the intuitions one builds when working with
traditional technology. One does what comes naturally with git, and
very quickly ends up with a steaming pile of bits. Which a git expert
could no doubt rescue, but which I was forced to remove and re-clone.
So I suppose I should list some of the things I like about git:
o It very naturally deals with remote repositories. If someone
holds your hand the first time, that is. ;-)
o Tagging works very nicely. In contrast, tagging in RCS is
quite painful and very easy to get wrong -- to the point that
I never bothered using it.
With git, I can easily tag the revision corresponding to a patch
sent to LKML and then very easily see what I have changed when
it is time to send the next version. Very handy and nice.
I suppose I could do the same thing with branches, and might
try that next.
o Moving among various branches works nicely -- as long as you
know the name of all the branches you need to know about.
o The "git diff" command usually does what I want with a minimum
of information -- though it sometimes feels the need to list
out the names of all the files that have not changed, for
reasons I do not yet understand. Still, I have often been
pleasantly surprised when it does what I wanted it to do despite
my having forgotten to type something I thought was essential.
o The fact that "git commit" lists all the files that changed but
are not being committed has saved me much time and trouble.
As has its listing the names of the files that -are- being
committed.
o I have only used "git rebase" a couple of times, but I could
see that I could come to like it very much.
See? I am already only partially a git hater! ;-)
Thanx, Paul
^ permalink raw reply
* Re: [RFC PATCH 0/2] Add support for multi threaded checkout
From: James Pickens @ 2008-12-19 1:04 UTC (permalink / raw)
To: devel; +Cc: git
In-Reply-To: <494ABDC9.9060001@morey-chaisemartin.com>
On Thu, Dec 18, 2008, Nicolas Morey-Chaisemartin
<devel@morey-chaisemartin.com> wrote:
> I guess you could do something like :
>
> #define checkout_lock() core_threaded_checkout ?pthread_mutex_lock(&checkout_mutex) : (void) 0
> #define checkout_unlock() core_threaded_checkout ?pthread_mutex_unlock(&checkout_mutex) : (void) 0
I tried that, and to make it easier to see the impact, I changed the
'wrote = write_in_full(...)' calls in entry.c to 'wrote = size'. That
makes git just create a bunch of empty files instead of writing the real
contents to disk. Here's the result, with core.threadedcheckout set to
false, best of 2 runs:
original patch: 3.19
original + above: 3.18
So the cost of locking/unlocking the mutex looks vanishingly small in the
single thread case.
This also puts an upper bound on the time required for a single thread to
unpack the data.
James
^ permalink raw reply
* Re: Odd merge behaviour involving reverts
From: Linus Torvalds @ 2008-12-19 0:46 UTC (permalink / raw)
To: Alan; +Cc: git
In-Reply-To: <1229646948.5770.33.camel@rotwang.fnordora.org>
On Thu, 18 Dec 2008, Alan wrote:
>
> So what is the recommended way to undo mistaken merges caught after the
> fact that will not fubar later merges?
Oh, I suspect reverting is the right thing, it's just that then you need
to remember to revert the revert if you intend to merge that branch again
later.
So reverting a merge isn't _wrong_ per se. It's just that you need to be
aware of the consequences, and if it becomes a common situation, you have
a problem in your usage patterns.
Btw, even with non-merge commits, "revert" can have interesting effects
exactly because it doesn't change history. For example, let's say that you
had a history like this, with two branches:
--> a --> b --> c --> d
|
+-> e --> !a
where the second branch reverts 'a', but the first one does not. What
happens when you merge the two branches? Is the revert sticky? In this
case, yes, a merge will cause the revert to stick. But what happens if you
had
--> a --> b --> c --> d
|
+-> e --> f --> !e
and 'b' and 'e' were the same patch (just applied in two different
branches), and '!e' reverts that patch in the second branch. What happens
to 'b' when you merge? Would you expect for 'b' to go away, since the
revert undid the same data in the second branch?
In that second case, the revert of 'e' will basically make git act as if
'e' didn't happen at all in the second branch, and so when you merge them,
'b' _will_ exist in the end result, so now the revert didn't "take".
All of this is very self-consistent (it's a very direct result of how
merges work and how revert works), but I'm just bringing these things up
as examples of how 'revert' is not a totally trivial matter. You'll always
find cases where you might have wished that it had acted differently when
you merge things.
Linus
^ permalink raw reply
* Re: [PATCH] Simplified GIT usage guide
From: C. Scott Ananian @ 2008-12-19 0:47 UTC (permalink / raw)
To: David Howells; +Cc: git, linux-kernel
In-Reply-To: <20081212182827.28408.40963.stgit@warthog.procyon.org.uk>
On Fri, Dec 12, 2008 at 1:28 PM, David Howells <dhowells@redhat.com> wrote:
> Add a guide to using GIT's simpler features.
> diff --git a/Documentation/git-haters-guide.txt b/Documentation/git-haters-guide.txt
> +In the above example, I've assumed that you've got your own tree with the head
> +at commit C3, and that you've got a branch that you want to merge, which has
> +its head at commit B3. After merging them, you'd end up with a directed,
> +cyclic tree:
That should be, "acyclic". There are no cycles, because the graph is directed.
--scott
--
( http://cscott.net/ )
^ permalink raw reply
* Re: git-rm -n leaves .git/index.lock if not allowed to finish
From: Junio C Hamano @ 2008-12-19 0:38 UTC (permalink / raw)
To: Miklos Vajna; +Cc: jidanni, git
In-Reply-To: <20081219002524.GB21154@genesis.frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> On Fri, Dec 19, 2008 at 04:02:48AM +0800, jidanni@jidanni.org wrote:
>> Bug: if git-rm -n is not allowed to write all it wants to write, it
>> will leave a .git/index.lock file:
>> # git-rm -n -r . 2>&1|sed q
>> error: '.etckeeper' has changes staged in the index
>> # git-rm -n -r . 2>&1|sed q
>> fatal: unable to create '.git/index.lock': File exists
>
> Can't reproduce:
>
> diff --git a/t/t3600-rm.sh b/t/t3600-rm.sh
> index b7d46e5..1581691 100755
> --- a/t/t3600-rm.sh
> +++ b/t/t3600-rm.sh
> @@ -251,4 +251,12 @@ test_expect_success 'refresh index before checking if it is up-to-date' '
>
> '
>
> +test_expect_success 'test from jidanni' '
> +
> + git reset --hard &&
> + git rm -n -r . 2>&1|sed q &&
> + git rm -n -r . 2>&1|sed q
> +
> +'
> +
> test_done
>
> passes here just fine. Yes, there are multiple files in the repo.
I think you need to have tons of files to cause the pipe buffer to fill up
with the "rm 'frotz'" output, triggering a SIGPIPE to kill the upstream
process of the pipe.
Would this patch help?
lockfile.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git i/lockfile.c w/lockfile.c
index 6d75608..8589155 100644
--- i/lockfile.c
+++ w/lockfile.c
@@ -140,6 +140,7 @@ static int lock_file(struct lock_file *lk, const char *path, int flags)
signal(SIGHUP, remove_lock_file_on_signal);
signal(SIGTERM, remove_lock_file_on_signal);
signal(SIGQUIT, remove_lock_file_on_signal);
+ signal(SIGPIPE, remove_lock_file_on_signal);
atexit(remove_lock_file);
}
lk->owner = getpid();
^ permalink raw reply related
* Re: git-rm -n leaves .git/index.lock if not allowed to finish
From: Junio C Hamano @ 2008-12-19 0:35 UTC (permalink / raw)
To: Miklos Vajna; +Cc: jidanni, git
In-Reply-To: <20081219002524.GB21154@genesis.frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> On Fri, Dec 19, 2008 at 04:02:48AM +0800, jidanni@jidanni.org wrote:
>> Bug: if git-rm -n is not allowed to write all it wants to write, it
>> will leave a .git/index.lock file:
>> # git-rm -n -r . 2>&1|sed q
>> error: '.etckeeper' has changes staged in the index
>> # git-rm -n -r . 2>&1|sed q
>> fatal: unable to create '.git/index.lock': File exists
>
> Can't reproduce:
>
> diff --git a/t/t3600-rm.sh b/t/t3600-rm.sh
> index b7d46e5..1581691 100755
> --- a/t/t3600-rm.sh
> +++ b/t/t3600-rm.sh
> @@ -251,4 +251,12 @@ test_expect_success 'refresh index before checking if it is up-to-date' '
>
> '
>
> +test_expect_success 'test from jidanni' '
> +
> + git reset --hard &&
> + git rm -n -r . 2>&1|sed q &&
> + git rm -n -r . 2>&1|sed q
> +
> +'
> +
> test_done
>
> passes here just fine. Yes, there are multiple files in the repo.
I think you need to have tons of files to cause the pipe buffer to fill up
with the "rm 'frotz'" output, triggering a SIGPIPE to kill the upstream
process of the pipe.
^ permalink raw reply
* Re: Odd merge behaviour involving reverts
From: Alan @ 2008-12-19 0:35 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.2.00.0812181614070.14014@localhost.localdomain>
On Thu, 2008-12-18 at 16:21 -0800, Linus Torvalds wrote:
>
> On Thu, 18 Dec 2008, Alan wrote:
> >
> > I think I know how to fix it. I am just concerned about having it occur
> > again if someone else makes the same mistake I did.
>
> I suspect we should warn about reverting merges. I'm surprised we don't
> already. Reverting a merge isn't "wrong", but it's a whole lot more subtle
> than reverting a regular commit.
>
> Reverting a regular commit just effectively undoes what that commit did,
> and is fairly straightforward. But reverting a merge commit also undoes
> the _data_ that the commit changed, but it does absolutely nothing to the
> effects on _history_ that the merge had.
>
> So the merge will still exist, and it will still be seen as joining the
> two branches together, and future merges will see that merge as the last
> shared state - and the revert that reverted the merge brought in will not
> affect that at all.
>
> So a "revert" undoes the data changes, but it's very much _not_ an "undo"
> in the sense that it doesn't undo the effects of a commit on the
> repository history.
>
> So if you think of "revert" as "undo", then you're going to always miss
> this part of reverts. Yes, it undoes the data, but no, it doesn't undo
> history.
So what is the recommended way to undo mistaken merges caught after the
fact that will not fubar later merges?
^ permalink raw reply
* Re: [PATCH] Simplified GIT usage guide
From: Junio C Hamano @ 2008-12-19 0:28 UTC (permalink / raw)
To: paulmck; +Cc: Johannes Schindelin, David Howells, torvalds, git, linux-kernel
In-Reply-To: <20081219000218.GA23990@linux.vnet.ibm.com>
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com> writes:
> On Fri, Dec 12, 2008 at 07:57:38PM +0100, Johannes Schindelin wrote:
> ...
>> I am sure we want to have something like that in git.git.
>
> So am I. Except that I am not being sarcastic. ;-)
Hmm, but we seem to already have too many intro-to-git documents in tree.
Perhaps good points in the document can be used to augment or replace
parts of existing documents? For example, which part of the new
documentation would have helped you avoid the pain you mentioned below...
> In particular, David's guide was quite helpful to me. It would have been
> even more helpful had it existed when I first tried (unsuccessfully)
> to use GIT. In particular, GIT's requirement that I tell it about new
> versions of existing files (either with "git add" or "git commit -a")
> was extremely counter-intuitive, and caused me no end of pain.
... and which part of the existing user manual or tutorial should have
talked about it to help you?
> But my experience is that git is at best an acquired taste for those of
> us who grew up with traditional source-code control systems. Such
> people will benefit greatly from a git-haters guide,...
"Acquired taste" is a much nicer and more diplomatic way to say the same
thing as what Linus often refers as "unlearning the braindamage inflicted
by years of using CVS." ;-)
> ..., and git's user
> population will grow as a result.
I do not think it constitutes any basis for judging the merit of having
the document in git.git tree. The world domination is not our goal, but
it may come as a mere side effect of being the best in the business.
^ permalink raw reply
* Re: git-rm -n leaves .git/index.lock if not allowed to finish
From: Miklos Vajna @ 2008-12-19 0:25 UTC (permalink / raw)
To: jidanni; +Cc: git
In-Reply-To: <87prjptfo7.fsf@jidanni.org>
[-- Attachment #1: Type: text/plain, Size: 821 bytes --]
On Fri, Dec 19, 2008 at 04:02:48AM +0800, jidanni@jidanni.org wrote:
> Bug: if git-rm -n is not allowed to write all it wants to write, it
> will leave a .git/index.lock file:
> # git-rm -n -r . 2>&1|sed q
> error: '.etckeeper' has changes staged in the index
> # git-rm -n -r . 2>&1|sed q
> fatal: unable to create '.git/index.lock': File exists
Can't reproduce:
diff --git a/t/t3600-rm.sh b/t/t3600-rm.sh
index b7d46e5..1581691 100755
--- a/t/t3600-rm.sh
+++ b/t/t3600-rm.sh
@@ -251,4 +251,12 @@ test_expect_success 'refresh index before checking if it is up-to-date' '
'
+test_expect_success 'test from jidanni' '
+
+ git reset --hard &&
+ git rm -n -r . 2>&1|sed q &&
+ git rm -n -r . 2>&1|sed q
+
+'
+
test_done
passes here just fine. Yes, there are multiple files in the repo.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply related
* Re: Odd merge behaviour involving reverts
From: Linus Torvalds @ 2008-12-19 0:21 UTC (permalink / raw)
To: Alan; +Cc: git
In-Reply-To: <1229645511.5770.29.camel@rotwang.fnordora.org>
On Thu, 18 Dec 2008, Alan wrote:
>
> I think I know how to fix it. I am just concerned about having it occur
> again if someone else makes the same mistake I did.
I suspect we should warn about reverting merges. I'm surprised we don't
already. Reverting a merge isn't "wrong", but it's a whole lot more subtle
than reverting a regular commit.
Reverting a regular commit just effectively undoes what that commit did,
and is fairly straightforward. But reverting a merge commit also undoes
the _data_ that the commit changed, but it does absolutely nothing to the
effects on _history_ that the merge had.
So the merge will still exist, and it will still be seen as joining the
two branches together, and future merges will see that merge as the last
shared state - and the revert that reverted the merge brought in will not
affect that at all.
So a "revert" undoes the data changes, but it's very much _not_ an "undo"
in the sense that it doesn't undo the effects of a commit on the
repository history.
So if you think of "revert" as "undo", then you're going to always miss
this part of reverts. Yes, it undoes the data, but no, it doesn't undo
history.
Linus
^ permalink raw reply
* Re: [PATCH 1/2] Add support for multi threaded checkout
From: Linus Torvalds @ 2008-12-19 0:13 UTC (permalink / raw)
To: James Pickens; +Cc: git
In-Reply-To: <885649360812181535h36d24b0gb31acddded452a0@mail.gmail.com>
On Thu, 18 Dec 2008, James Pickens wrote:
> On Thu, Dec 18, 2008, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> > So instead of doing all the unpacking etc in parallel (with locking around
> > it to serialize it), I'd suggest doing ll the unpacking serially since
> > that isn't the problem anyway (and since you have to protect it with a
> > lock anyway), and just have a "write out and free the buffer" phase that
> > is done in the threads.
>
> That's certainly a more elegant way to do it, but unless I'm missing
> something, it requires rewriting a good bit of code. The main reason I
> went with the locking was to keep the patch as simple and non-intrusive
> as possible.
Yeah, I looked a bit more at it, and one problem is that we don't just
write out the file, we also refresh the cache with the stat information
after writing it out. If we just write the thing out, it would be simpler:
we'd just make the thread locklessly write things out and free the data
from a simple set of lockless threads - no need for any access to git data
structures.
Ho humm. I'll think about it a bit more.
Linus
^ permalink raw reply
* Re: Odd merge behaviour involving reverts
From: Alan @ 2008-12-19 0:11 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.2.00.0812181534310.14014@localhost.localdomain>
On Thu, 2008-12-18 at 15:58 -0800, Linus Torvalds wrote:
>
> On Thu, 18 Dec 2008, Alan wrote:
> >
> > What am i doing wrong here?
>
> Reverting a merge is your problem.
>
> You can do it, but you seem to have done it without understanding what it
> causes.
Obviously.
> A revert of a merge becomes a regular commit that just undoes everything
> that the merge did in your branch. When you then do the next merge, you'll
> do that merge with that in mind, so now git will essentially consider the
> previous merge to be the base line, but your revert undid everything that
> that one brought in, so the new merge will really only contain the new
> stuff from the branch you are merging.
So I will have to look for previous reverts (or "pre-verts") before
merging again.
> So if a merge causes problems, you generally should either undo it
> _entirely_ (ie do a 'git reset --hard ORIG_HEAD'), not revert it.
>
> Of course, if you had already made the merged state public, or done
> development on top of it, you can't really do that. In which case a revert
> works, but if you want it back, you should revert the revert, not merge
> the branch again - because what you merged last time you threw away, and
> won't be applied again.
On this code base, there were 30+ branches merged before the powers that
be decided to have me pull that one. It was in the middle of the pile.
I think I know how to fix it. I am just concerned about having it occur
again if someone else makes the same mistake I did.
Thanks.
^ permalink raw reply
* Re: [PATCH][RESEND] guilt: add option guilt.diffstat
From: Wu Fengguang @ 2008-12-19 0:08 UTC (permalink / raw)
To: Josef Jeff Sipek; +Cc: git@vger.kernel.org, Boyd Stephen Smith Jr.
In-Reply-To: <20081218143918.GM15407@josefsipek.net>
On Thu, Dec 18, 2008 at 04:39:18PM +0200, Josef Jeff Sipek wrote:
> On Thu, Dec 18, 2008 at 07:26:43PM +0800, Wu Fengguang wrote:
> > Introduce option guilt.diffstat so that we don't have to type
> > "guilt refresh --diffstat" in its full form every time.
>
> I haven't forgotten about this. I'll try to apply it tonight/tomorrow
> morning.
Thank you. This refreshed patch resolved merge conflict against the
latest git tree :)
Thanks,
Fengguang
^ permalink raw reply
* Re: [PATCH] Simplified GIT usage guide
From: Paul E. McKenney @ 2008-12-19 0:02 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: David Howells, torvalds, git, linux-kernel
In-Reply-To: <alpine.DEB.1.00.0812121952320.5873@eeepc-johanness>
On Fri, Dec 12, 2008 at 07:57:38PM +0100, Johannes Schindelin wrote:
> Hi,
>
> On Fri, 12 Dec 2008, David Howells wrote:
>
> > Documentation/git-haters-guide.txt | 1283 ++++++++++++++++++++++++++++++++++++
>
> I am sure we want to have something like that in git.git.
So am I. Except that I am not being sarcastic. ;-)
> > +I don't really know what I'm doing with GIT either.
>
> Strike the "either".
Not in my case. And I am far from alone.
Let's face it, if you really do know what you are doing with GIT, you
probably are not a GIT-hater, and thus not in the target audience for
Dave's document.
> > +===============
> > +OVERVIEW OF GIT
> > +===============
>
> Your overview seems to be what "Git from the bottom up" is all about (see
> the Git Wiki for more information where to find it).
>
> From my experience with new users, this is exactly the wrong way to go
> about it. You don't introduce object types of the Git database before
> telling the users what the heck they are good for. And most users do not
> need to bother with tree objects either, anyway. So maybe you just tell
> them what the heck the object types are good for, without even teaching
> them the object types at all.
>
> So I think that your document might do a good job scaring people away from
> Git. But I do not believe that your document, especially in the tone it
> is written, does a good job of helping Git newbies.
>
> Ciao,
> Dscho
>
> P.S.: No, I haven't read the whole document. Still, I think I am
> qualified enough to estimate what the average reader's first impression
> would be.
Not sure I agree. You might well know too much about git to understand
what it looks like to a new user, particularly a new user with a
couple decades experience with earlier source-code control system.
(RCS, anyone?)
In particular, David's guide was quite helpful to me. It would have been
even more helpful had it existed when I first tried (unsuccessfully)
to use GIT. In particular, GIT's requirement that I tell it about new
versions of existing files (either with "git add" or "git commit -a")
was extremely counter-intuitive, and caused me no end of pain.
There might well be a need for different approaches for different types
of newbies. Guys like myself who have used source-code control tools
of one type or another for a couple decades can -definitely- benefit
from Dave's approach. In particular, Dave's broad-brush description of
GIT's internals is enough to explain why the heck I should have to tell
GIT about a new version of a file THAT IT ALREADY KNOWS ABOUT!!!
"Why should I need to add a file that is already there???"
Don't get me wrong -- as I have gained experience with GIT over the past
six months or so, I have found a number of situations where GIT's
insisting that I tell it about new versions of existing files has been
helpful, for example, when I suddenly realize that a given change should
be applied in multiple commits, with different groups of files in each
commit. In that case, doing a series of "git add" and "git commit"
commands works very nicely.
So I am -not- suggesting changing git. Once you get used to it, it
works out well. I suppose that you could have a "git new-version"
command as a synonym for "git add", but I doubt that it is worth it.
But the "git add" issue turned me away from git several times in the past
three years. And for quite some time, I used git in read-only mode,
because very strange things happened (from my viewpoint) whenever I
tried changing anything.
After using GIT reasonably heavily for the past six months, I am actually
learning to like it, and have even starting using it for my own projects.
But my experience is that git is at best an acquired taste for those of
us who grew up with traditional source-code control systems. Such
people will benefit greatly from a git-haters guide, and git's user
population will grow as a result.
Thanx, Paul
^ permalink raw reply
* Re: Odd merge behaviour involving reverts
From: Linus Torvalds @ 2008-12-18 23:58 UTC (permalink / raw)
To: Alan; +Cc: git
In-Reply-To: <1229642734.5770.25.camel@rotwang.fnordora.org>
On Thu, 18 Dec 2008, Alan wrote:
>
> What am i doing wrong here?
Reverting a merge is your problem.
You can do it, but you seem to have done it without understanding what it
causes.
A revert of a merge becomes a regular commit that just undoes everything
that the merge did in your branch. When you then do the next merge, you'll
do that merge with that in mind, so now git will essentially consider the
previous merge to be the base line, but your revert undid everything that
that one brought in, so the new merge will really only contain the new
stuff from the branch you are merging.
So if a merge causes problems, you generally should either undo it
_entirely_ (ie do a 'git reset --hard ORIG_HEAD'), not revert it.
Of course, if you had already made the merged state public, or done
development on top of it, you can't really do that. In which case a revert
works, but if you want it back, you should revert the revert, not merge
the branch again - because what you merged last time you threw away, and
won't be applied again.
Linus
^ permalink raw reply
* Re: [PATCH] fast-export: deal with tag objects that do not have a tagger
From: Miklos Vajna @ 2008-12-18 23:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git, scott
In-Reply-To: <7viqphf4ua.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 771 bytes --]
On Thu, Dec 18, 2008 at 03:20:29PM -0800, Junio C Hamano <gitster@pobox.com> wrote:
> Such a "faking" can well be done, and should be done, on the consuming end
> of the information. If you fake using the commit authorship, you would
> never be able to tell from the result which one is faked and which one is
> genuine.
>
> I think you'd rather want to see "Unspecified Tagger" in the resulting tag
> object (or even better, a tag object without the tagger field created by
> the fast-import process), and leave the interpretation of missing tagger
> information to the consumers.
Aah, I missed that Dscho's patch will not just not die(), but it _will_
output a stream that fast-import will import. So just forget my
complain. :-)
And Dscho, thanks!
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] Add support for multi threaded checkout
From: James Pickens @ 2008-12-18 23:35 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.2.00.0812181333150.14014@localhost.localdomain>
On Thu, Dec 18, 2008, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> So instead of doing all the unpacking etc in parallel (with locking around
> it to serialize it), I'd suggest doing ll the unpacking serially since
> that isn't the problem anyway (and since you have to protect it with a
> lock anyway), and just have a "write out and free the buffer" phase that
> is done in the threads.
That's certainly a more elegant way to do it, but unless I'm missing
something, it requires rewriting a good bit of code. The main reason I
went with the locking was to keep the patch as simple and non-intrusive
as possible.
> The alternative would be to actually do what your patch suggests, but
> actually try to make the code git SHA1 object handling be thread-safe. At
> that point, the ugly locking in write_entry() would go away, and you might
> actually improve performance on SMP thanks to doing the CPU part in
> parallel.
I started down that path at one point, and quickly got in over my head.
Making all that code thread safe looks like a big task to me. From my
perspective, I get a ~350% speedup from this easy patch, and I might get
an additional 25% (blind guess) from a much more difficult patch. It
didn't seem worth the effort.
James
^ permalink raw reply
* Odd merge behaviour involving reverts
From: Alan @ 2008-12-18 23:25 UTC (permalink / raw)
To: git
I am encountering an odd problem with how merging branches are working.
I expect I am doing something wrong, I just need to know what.
Here is my situation...
I have a master branch. We have a branch off of that that some
developers are doing work on. They claim it is ready. We merge it into
the master branch. It breaks something so we revert the merge. They
make changes to the code. they get it to a point where they say it is
ok and we merge again.
When examined, we find that code changes made before the revert are not
in the master branch, but code changes after are in the master branch.
We now have code that does not contain all of the changes in the branch.
Is there a different way to undo merges into a branch that does not
block further merges from that branch?
What am i doing wrong here?
^ permalink raw reply
* Re: [PATCH] fast-export: deal with tag objects that do not have a tagger
From: Junio C Hamano @ 2008-12-18 23:20 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Johannes Schindelin, git, scott
In-Reply-To: <20081218213407.GX5691@genesis.frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> On Thu, Dec 18, 2008 at 08:45:44PM +0100, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>> I think so. The responsible code is in fast-export.c, in any
>> case. Of course, fast-import refuses to import a tag without a
>> tagger, so...
>
> That's why I asked. I think it's a reasonable assumption that in most
> cases the tagger and the committer of the tagged commit is the same. So
> in case the tagger info is missing and we tag a commit, we could fake
> that info on export.
>
> Obviously this should not be the default, but I think such a mode would
> be useful in real-life.
Such a "faking" can well be done, and should be done, on the consuming end
of the information. If you fake using the commit authorship, you would
never be able to tell from the result which one is faked and which one is
genuine.
I think you'd rather want to see "Unspecified Tagger" in the resulting tag
object (or even better, a tag object without the tagger field created by
the fast-import process), and leave the interpretation of missing tagger
information to the consumers.
^ permalink raw reply
* Re: negated list in .gitignore no fun
From: Boyd Stephen Smith Jr. @ 2008-12-18 22:34 UTC (permalink / raw)
To: jidanni; +Cc: git, joey
In-Reply-To: <87hc51tajw.fsf@jidanni.org>
[-- Attachment #1: Type: text/plain, Size: 1071 bytes --]
On Thursday 2008 December 18 15:53:23 jidanni@jidanni.org wrote:
> # head -n 5 .gitignore
> *
> !X11/xorg.conf
> !anacrontab
> !apt/apt.conf.d/10jidanni
> !apt/sources.list
> # git-add .
> But git-status only shows anacrontab got added. None of the files in
> the subdirectories get added.
That's by design. You've chosen to ignore those directories; they match "*"
themselves. Thus, 'git add .' doesn't descend into them looking for files.
I wouldn't want to change this behavior because I'll often use a "build"
directory and put all generated files in it and just ignore that directory
with a single line in .gitignore.
I think the .gitignore you really want is:
*
!X11
!X11/xorg.conf
!anacrontab
!apt
!apt/apt.conf.d
!apt/apt.conf.d/10jidanni
!apt/sources.list
[...]
But, I haven't tested that.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: negated list in .gitignore no fun
From: Linus Torvalds @ 2008-12-18 22:54 UTC (permalink / raw)
To: jidanni; +Cc: git, joey
In-Reply-To: <alpine.LFD.2.00.0812181429100.14014@localhost.localdomain>
On Thu, 18 Dec 2008, Linus Torvalds wrote:
>
> So you have several possibilities:
>
> (a) either create a .gitignore that looks like this:
>
> *
> !X11
> !X11/xorg.conf
> !anacrontab
> !apt
> !apt/apt.conf.d
> !apt/apt.conf.d/10jidanni
> !apt/sources.list
>
> which should work around it by telling git that it shouldn't ignore
> the subdirectories.
Oh, you should have a '/' there in the subdirectory marker too, because
otherwise a file like 'X11/apt' would now match as a positive match.
> (c) Try to teach git to not ignore subdirectories leading up to
> non-ignored files, and give you the .gitignore semantics you like. I
> suspect it's not worth it, because the git behaviour is logical once
> you know about it and understand it.
.. and because of subtle issues like this - negated entries are really
quite complex enough as-is. Don't use them for anything subtle, you _will_
get them wrong regardless.
Linus
^ permalink raw reply
* Re: negated list in .gitignore no fun
From: Linus Torvalds @ 2008-12-18 22:38 UTC (permalink / raw)
To: jidanni; +Cc: git, joey
In-Reply-To: <87hc51tajw.fsf@jidanni.org>
On Fri, 19 Dec 2008, jidanni@jidanni.org wrote:
>
> I had dreams of tracking only a few files in a large tree.
> I thought I would maintain that list as a negated list in .gitignore,
> and then always use "git-add ." to keep git's index reflecting my list.
>
> However that's just not possible.
>
> # head -n 5 .gitignore
> *
> !X11/xorg.conf
> !anacrontab
> !apt/apt.conf.d/10jidanni
> !apt/sources.list
> # git-add .
> But git-status only shows anacrontab got added. None of the files in
> the subdirectories get added.
Yeah, the problem is that the '*' matches the subdirectories (like "X11"),
but the negative matching does not. So the subdirectory gets ignored, and
as a result, git won't even traverse into it and notice that there's a
file in there that shouldn't be ignored.
It's actually logical, but not what you want.
So you have several possibilities:
(a) either create a .gitignore that looks like this:
*
!X11
!X11/xorg.conf
!anacrontab
!apt
!apt/apt.conf.d
!apt/apt.conf.d/10jidanni
!apt/sources.list
which should work around it by telling git that it shouldn't ignore
the subdirectories.
(b) realize that ".gitignore" only matters for files that git doesn't
already know about, so if you only want to track a small set of
files, what you _should_ do is just do a .gitignore that looks like
this:
*
and then just force-add the few files you want to track, using
something like
git add -f X11/xorg.conf anacrontab apt/apt.conf.d/10jidanni apt/sources.list
and now you're done - git won't ignore them, since explciitly you
told git to track them.
(c) Try to teach git to not ignore subdirectories leading up to
non-ignored files, and give you the .gitignore semantics you like. I
suspect it's not worth it, because the git behaviour is logical once
you know about it and understand it.
.. and possibly other things you could do too.
Linus
^ permalink raw reply
* negated list in .gitignore no fun
From: jidanni @ 2008-12-18 21:53 UTC (permalink / raw)
To: git; +Cc: joey
I discovered git is so negative: it has very good .gitignore negative
matching facilities, but not as good positive matching facilities.
(Maybe positive glob lists are merely fed to git-add from the command line.)
I had dreams of tracking only a few files in a large tree.
I thought I would maintain that list as a negated list in .gitignore,
and then always use "git-add ." to keep git's index reflecting my list.
However that's just not possible.
# head -n 5 .gitignore
*
!X11/xorg.conf
!anacrontab
!apt/apt.conf.d/10jidanni
!apt/sources.list
# git-add .
But git-status only shows anacrontab got added. None of the files in
the subdirectories get added. We continue,
# sed -n s/^!//p .gitignore|xargs git-add #no help!
# sed -n s/^!//p .gitignore|xargs -n 1 git-add #Geez. Finally worked.
OK, I suppose my next step is just to rm .gitignore and just add any
future files I want to add to my list one by one with git-add... like
git was designed to do in the first place. OK, thanks. Bye.
Next episode: some kind of middle ground with etckeeper.
^ 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