* Re: [PATCH] git-daemon documentation: use {tilde}
From: Miklos Vajna @ 2008-12-16 17:50 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Junio C Hamano, git
In-Reply-To: <4947E7B1.2090608@drmicha.warpmail.net>
[-- Attachment #1: Type: text/plain, Size: 364 bytes --]
On Tue, Dec 16, 2008 at 06:38:57PM +0100, Michael J Gruber <git@drmicha.warpmail.net> wrote:
> Curiously, "git help daemon" (which execs "man git-daemon") displays the
> tilde but "man git-daemon" does not (nor does "konqueror
> man:git-daemon"). Humh?
'git help daemon' is wrong for me - without the patch - as well.
(Though I never use the git help foo form.)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Git Notes idea.
From: Govind Salinas @ 2008-12-16 18:43 UTC (permalink / raw)
To: Jeff King; +Cc: Git Mailing List
In-Reply-To: <20081216085108.GA3031@coredump.intra.peff.net>
On Tue, Dec 16, 2008 at 2:51 AM, Jeff King <peff@peff.net> wrote:
> On Tue, Dec 16, 2008 at 02:15:47AM -0600, Govind Salinas wrote:
>
>> I was thinking about possible ideas for my little pet project and I
>> had and idea for way to tack on notes to a commit, or any object
>> really. I know that the idea has been flying around for a long time
>> but there has never been any implementation or a concept that people
>> liked enough to use (unless I have missed something).
>
> I think you look at the previous suggestions, because yours is very
> similar. Which is good, I think, because the current status is that the
> design is good, but nobody has gotten around to working on it yet. So
> maybe you can fix that. :)
>
I was thinking I would do my first implementation in pyrite and if I find
that it works well I will port it.
>> .git/refs/notes contains a tree-id (assuming that using a tree-id
>> will not cause any problems, otherwise a commit object can be used.
>> it does not *need* a history, but it *could* have one).
>
> That is the same as the current proposal, except:
>
> - the proposal is to use a commit, so your notes are version-controlled
>
> - I have suggested supporting multiple note "bases" in the refs/notes
> namespace. This would allow you to share some notes but not others
> (e.g., if you had some automated notes related to a build/test
> system, you might not want to mix those with your human-written
> notes).
>
>> That tree has a structure similar to the layout of .git/objects, where
>> it is 2 letter subdirectories for the notes objects.
>
> I don't think this has been suggested yet, but I'm not sure it is a good
> idea. The usual reason for this split is that many filesystems handle
> large directories badly; that isn't a problem here.
>
I just read the proposal from Johannes, he seems to want to use a
similar layout. However, I would like to modify my proposal slightly
to make it work better when a gc is run. I would modify the tree to
look like this...
let 1234567890123456789012345678901234567890 be the
id of the item that is annotated.
let abcdef7890123456789012345678901234567890 be the
id of the note to be attached
root/
12/
34567890123456789012345678901234567890/
abcdef7890123456789012345678901234567890
This way all the notes are attached to a tree, so that gc won't
think they are unreferenced objects.
> It does reduce the size of the resulting tree objects when a note is
> modified (we make updates to two smaller trees instead of one big tree).
> I don't know if this really matters all that much, since the trees
> will end up deltified in a pack anyway.
>
> And it does make the implementation slightly less simple, since we have
> to deal with two levels of trees.
>
>> Given a git object (commit, tree, blob, tag), use its sha as the
>> path/filename in this tree.
>> If I have a commit 1234567890123456789012345678901234567890 then
>> the notes tree will have a file
>> 12/34567890123456789012345678901234567890
>>
>> That file has a list of sha1s (one per line). These shas are object
>> IDs for blobs that have the notes or whatever that you want attached
>> to the item.
>
> This is slightly different than the current proposal. You are proposing
> that each item have a "list of notes". My thinking was to have "named
> notes" using a tree for each entry full of blobs. So you could look up
> the "foo" note for a given commit, but that note would be a single
> scalar (which could, of course, be interpreted according to its name).
>
>> I think you get the idea. When looking up an item, it should be
>> fairly easy to have the notes tree and subtrees available for doing
>> lookups. And as far as I know stuff under .git/refs can be
>
> It is easy, but it's slow because we have to do a linear search in the
> (potentially huge) notes tree. And that's what held up the initial
> implementation. I did a proof-of-concept a month or so ago that
> pre-seeded an in-memory hash using the tree contents and got pretty
> reasonable performance.
>
Perhaps I am missing something, how is it a linear search?. Since we
are keying off of the sha of the annotated object, using a hashtable for
a cache should be a fairly quick binary search. If you just wanted to
use the tree objects, that should work almost as well since the first tree
will split them up nicely for you.
Also, how large do you expect the list to be under reasonable
circumstances.
>> pushed/pulled even if its not under heads or remotes or tags using
>> already existing machinery. I am not sure, but I think that would
>> satisfy gc operations as well. Also, these trees and blobs never have
>> to be put in the working directory.
>
> Right, though I think one of the benefits of this approach is that you
> _could_ do a checkout on the notes tree if you wanted to do very
> flexible editing.
>
Sure, why not.
>> Does this sound like something that is workable? I thought it might
>> appeal since it uses only features that are already present.
>
> Yes, it sounds workable, though if you diverge from what has already
> been discussed, I think you should make an argument about why your
> approach is better.
>
Well after reading Johannes proposal, I find it to be surprisingly similar
since I had not seen it before. However I think mine is a win in a few ways.
One, it allows multiple notes per object. Two, it plays well with gc. From
what I could follow, the files in his layout just have a ref to the note object
but gc would be required to know about this feature and not remove those
note blobs. Third it allows multiple sets of notes. Although it seems that
at least 1 and 3 have been discussed at some length.
>> This could be extended so that you have different sets of notes under
>> .git/refs/notes/<my note set> or whatever. So that you can have some
>> notes you keep private and some that you publish or whatever.
>
> Oops, I should have read your whole mail. Yes, that is a good idea. :)
>
> For reference, here are the previous discussions that I think are
> relevant:
>
Thanks for the pointers, a couple quick thoughts...
> Some discussion of the interaction of notes and rebase:
> http://thread.gmane.org/gmane.comp.version-control.git/100533
>
On rebasing, I have a couple thoughts. 1) I think it only really makes
sense to make a public annotation to a commit that is public, and
once a commit is public it should not be rebased. 2) We could also
annotate the commit's tree instead of the commit. That would make
it somewhat resistant to rebases, cherry-picks and amends. And
once a tree has changed, the notes are probably less reliable
although the user should be able to force a note or notes to be
carried along.
> Some thoughts from me on naming issues:
> http://article.gmane.org/gmane.comp.version-control.git/100402
>
On naming. I strongly support a ref/notes/sha1/sha1 approach. If
having a type to the note is important, then perhaps the first line of
a note could be considered a type or a set of "tags". This way you
have both naming/typing and one lookup per sha. The only
drawback is that you have to open the blob to see the type. A hybrid
approach that uses refs/notes/acked/sha/sha which is one lookup if
you know the type and the sha of the annotated object before hand
might be worth considering. This would be similar to the public or
private notes that i mentioned before.
> Some thoughts from me on the tree speedup:
> http://article.gmane.org/gmane.comp.version-control.git/101460
>
I guess I must be missing something. I have seen several references
to this not being a binary search several times in the links that you have
here. But I fail to see why a binary search cannot be done. That said, I
would still think that the existing hash table would be the way to go.
> which I think should bring you up to speed. :)
Thanks again.
-Govind
^ permalink raw reply
* Re: [PATCH] git-daemon documentation: use {tilde}
From: Matthieu Moy @ 2008-12-16 18:05 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Miklos Vajna, Junio C Hamano, git
In-Reply-To: <4947E7B1.2090608@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
> Miklos Vajna venit, vidit, dixit 16.12.2008 16:48:
>> Use '{tilde}' instead of '~', becase the later does not appear in the
>> manpage version, just in the HTML one.
>
> Curiously, "git help daemon" (which execs "man git-daemon") displays the
> tilde but "man git-daemon" does not (nor does "konqueror
> man:git-daemon"). Humh?
You probably have two manpages because of two git installations. "man"
will take the one in your manpath, and git will try to find the one
corresponding to the version of git you actually launched.
--
Matthieu
^ permalink raw reply
* Re: Git weekly news: 2008-50
From: Felipe Contreras @ 2008-12-16 19:49 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git list
In-Reply-To: <m38wqjg1n1.fsf@localhost.localdomain>
On Sun, Dec 14, 2008 at 12:18 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> "Felipe Contreras" <felipe.contreras@gmail.com> writes:
>
>> This week I'm trying to address some of the issues mentioned here. I
>> still would like people to request user accounts to this blog if they
>> wish to make some git related posts.
>>
>> http://gitlog.wordpress.com/2008/12/13/git-weekly-links-2008-50/
>>
>> == Articles ==
>>
>> Why Subversion does not suck
>> http://blog.assembla.com/assemblablog/tabid/12618/bid/7437/Why-Subversion-does-not-suck.aspx
> [...]
>
> Thanks a lot. I quite like the new format, both HTML version on blog,
> and the format used here in this email.
Cool :)
> P.S. Small nitpick: you have changed the title of blog post, but not
> subject of email.
Ah, thanks, I didn't notice.
--
Felipe Contreras
^ permalink raw reply
* how to work in hirarchical git model?
From: Gili Pearl @ 2008-12-16 22:26 UTC (permalink / raw)
To: git
[Not sure I'm posting to the right mailing list; sorry in advance]
I’m working in a small company with about 15 developers. So far we were all
rebasing our local repos on a single main repo. When one had some new commits,
he rebased them on the main-repo/master and asked the main-repo maintainer to
pull them in. So far so good, but we now considering moving into a three level
model, where we’ll have sub-maintainers that will handle local merges before
they hit the main-repo. I’m not sure I understand how this is supposed to work
and I’d be thankful to get some advice.
Here is one problem I saw when trying to work in the three-level model.
At some point, I had the following setup:
top-level : A----B----C----D
\
\
mid-level1: K----L----M
\
\
low-level1: X----Y
The maintainer of mid-level1 has decided that commits K L M are ready to be
merged into the top-level repo. So he rebased on top-level before asking 'please
pull', but after that the low-level was not able to rebase on the mid-level
any more.
I can understand that the problem is because commit L had become L', and now
low-level1 cannot find L anymore, i.e. now it looks like this:
top-level : A----B----C----D
\
\
mid-level1: K'----L'----M'
\
\
low-level1: X----Y
... but I guess this is not how it should work. So what is the right working
flow for us?
Thanks.
^ permalink raw reply
* git ignore
From: Max Power @ 2008-12-16 22:43 UTC (permalink / raw)
To: git
So I understand how to use the .gitignore file to ignore specific
files/directories that I put in there... is there a way to ignore everything
BUT a given file extension?
--
View this message in context: http://www.nabble.com/git-ignore-tp21043430p21043430.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: git-diff should not fire up $PAGER if there is no diff
From: Stefan Karpinski @ 2008-12-16 22:43 UTC (permalink / raw)
To: Jeff King; +Cc: jidanni, git
In-Reply-To: <20081216074414.GB2468@coredump.intra.peff.net>
On Tue, Dec 16, 2008 at 2:44 AM, Jeff King <peff@peff.net> wrote:
> On Tue, Dec 16, 2008 at 01:35:53AM -0500, Stefan Karpinski wrote:
>
>> > On Mon, Dec 15, 2008 at 7:56 PM, Jeff King <peff@peff.net> wrote:
>> > 2. detect EOF before starting the pager. We in fact already delay
>> > running the pager in the forked process until we have some activity
>> > on the pipe, but I don't know if there is a portable way of
>> > detecting that that activity is EOF without performing an actual
>> > read() call (which is undesirable, since it eats the first byte of
>> > output that should go to the pager).
>>
>> Wouldn't ungetc work? Or is that not portable enough? (It would only
>> work here because the EOF has to be the first character.)
>
> No, it won't work. ungetc works on the buffered stdio object, so it is
> useful for pushing back characters onto the buffer to be read later in
> the program from the same buffer. But in this case, we are going to
> execv() (or on Windows, spawn) the pager, meaning it will throw away
> anything that has been read() from the pipe and put in the buffer.
>
> So we would need a system call to push a character back to the OS, so
> that it was available for read() by the pager process.
Yeah, I realized that after I sent the message. Late night sending bad!
^ permalink raw reply
* Re: git ignore
From: Linus Torvalds @ 2008-12-16 22:53 UTC (permalink / raw)
To: Max Power; +Cc: git
In-Reply-To: <21043430.post@talk.nabble.com>
On Tue, 16 Dec 2008, Max Power wrote:
>
> So I understand how to use the .gitignore file to ignore specific
> files/directories that I put in there... is there a way to ignore everything
> BUT a given file extension?
Something like
*
!*.jpg
to only save the jpegs in your pr0n collection?
The first rule says "ignore everything". The second one says "don't
ignore *.jpg files".
Untested.
Linus
^ permalink raw reply
* Re: git ignore
From: Junio C Hamano @ 2008-12-16 23:08 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Max Power, git
In-Reply-To: <alpine.LFD.2.00.0812161450010.14014@localhost.localdomain>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Tue, 16 Dec 2008, Max Power wrote:
>>
>> So I understand how to use the .gitignore file to ignore specific
>> files/directories that I put in there... is there a way to ignore everything
>> BUT a given file extension?
>
> Something like
>
> *
> !*.jpg
>
> to only save the jpegs in your pr0n collection?
Hmm, do people still keep p0rn collection in jpgs? I somehow had an
impression that they moved to avis ;-)
> The first rule says "ignore everything". The second one says "don't
> ignore *.jpg files".
>
> Untested.
t3001-ls-files-others-exclude.sh has some tests but there is nothing that
explicitly tests overlapping patterns. Perhaps it should (hint, hint...)
"man gitignore" documentation has an example to ignore all *.html files
but not foo.html using a similar construct, i.e.
*.html
!foo.html
^ permalink raw reply
* Strange untracked file behaviour
From: Miklos Vajna @ 2008-12-16 23:24 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 921 bytes --]
Hi,
Here is a copy of the udev repo I cloned some time ago:
http://frugalware.org/~vmiklos/files/udev.tar.bz2
I did not modify it, so I thought a simple 'git pull' can update it.
$ git pull
Updating 661a0be..b6626d0
error: Untracked working tree file 'test/sys/class/misc/rtc/dev' would
be removed by merge.
Ok, let's clean the untracked files:
$ git clean -x -d -f
But it does not remove any file.
$ git ls-files|grep test/sys/class/misc/rtc/dev
test/sys/class/misc/rtc/dev
So it seems git-clean is right.
$ git pull -s resolve
Updating 661a0be..b6626d0
error: Untracked working tree file 'test/sys/class/misc/rtc/dev' would
be removed by merge.
So it does not seem to be merge-recursive-related.
Does somebody have an idea what's going on? :)
$ git version
git version 1.6.1.rc1.35.gae26e.dirty
('dirty' is due to non-code changes in my working directory.)
Let me know if you need more details.
Thanks.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Git Notes idea.
From: Johannes Schindelin @ 2008-12-16 23:48 UTC (permalink / raw)
To: Govind Salinas; +Cc: Jeff King, Git Mailing List
In-Reply-To: <5d46db230812161043m4a5873a8w4c323d634b639ba0@mail.gmail.com>
Hi,
On Tue, 16 Dec 2008, Govind Salinas wrote:
> I was thinking I would do my first implementation in pyrite and if I
> find that it works well I will port it.
Given that there are a lot of building blocks in C already, I think it
would be a waste of your time.
> I just read the proposal from Johannes, he seems to want to use a
> similar layout. However, I would like to modify my proposal slightly to
> make it work better when a gc is run. I would modify the tree to look
> like this...
>
> let 1234567890123456789012345678901234567890 be the
> id of the item that is annotated.
>
> let abcdef7890123456789012345678901234567890 be the
> id of the note to be attached
>
> root/
> 12/
> 34567890123456789012345678901234567890/
> abcdef7890123456789012345678901234567890
>
> This way all the notes are attached to a tree, so that gc won't
> think they are unreferenced objects.
In my proposal back then, your root/12/345... would be a blob, in Peff's,
it would be a tree, and in both cases the blobs/trees would be referenced
by refs/notes, so git gc would not kill them either.
The bigger issue is that commit objects can be gc'ed, and then their notes
should be gc'ed, too.
And of course, there is the rebase issue (which I completely missed; I
will read the mail Jeff referenced tomorrow).
Speaking about the blobs vs trees issue, I think it is no issue, as Peff
and me already discussed: the notes could check if it is a tree or a
blob, and handle both easily.
> Peff wrote:
>
> > It is easy, but it's slow because we have to do a linear search in the
> > (potentially huge) notes tree. And that's what held up the initial
> > implementation. I did a proof-of-concept a month or so ago that
> > pre-seeded an in-memory hash using the tree contents and got pretty
> > reasonable performance.
>
> Perhaps I am missing something, how is it a linear search?
Yes, you are missing what I wrote in the original thread: tree objects
must be read in a forward direction, one by one.
IIRC back then, Junio and/or Linus suggested that you could backward
search with heuristics finding the beginning of a tree entry, and thus you
could kind of bisect the tree to search for a specific tree entry (since
tree objects have the contents sorted), but I presented a case where this
breaks down at the GitTogether:
Tree entries consist of a mode (as 6-byte ASCII representing the octal
value), then SPC, then a NUL-terminated path, and then a 20-byte SHA-1.
(Just hexdump the output of "git cat-file tree HEAD:" in any repository to
see it).
The only heuristic you could apply to find your way backward (or forward)
to find the beginning of a tree entry would be to find the NUL character
and verify that exactly 20 bytes after it, either the tree object ends, or
there is a valid octal number followed by a SPC.
The only thing you would need for this heuristic to break down is a SHA-1
which contains a \x00 (which is then mistaken for a string termination),
and part of a filename that could be mistaken to be an octal number.
Take for example the SHA-1 of git-gui in v1.6.0.5, which has a NUL its
14th byte, and just assume that the next tree entry has mode 100644
and name "4040000 Some financial record.txt".
Then, the NUL could be mistaken for the end of the previous tree entry,
and "040000 " as the mode for the next one, whose name would be assumed to
be "Some financial record.txt".
Granted, if you find two NULs in 21 bytes, one of them must be the
termination of the path, but which one?
Worse, even if you would find a method (complicated, and therefore
necessarily fragile) to find the boundary of the tree entries reliably,
you would _still_ have a linear time unpacking the darned tree object in
the first place.
So you cannot do that for every commit you encounter and expect not to die
of boredom in the process.
Peff's very cute idea was to decouple that process from the per-commit
procedure, and basically make it a one-time cost (per Git call, and only
when notes were asked for).
It will still be linear in the number of notes, but it would then be in a
hashmap, with an expected linear cost per commit.
> Also, how large do you expect the list to be under reasonable
> circumstances.
We did not intend Git to be used as a backup tool, did we?
One of the _worst_ design decisions is to limit yourself by expectations.
> > Some discussion of the interaction of notes and rebase:
> > http://thread.gmane.org/gmane.comp.version-control.git/100533
>
> On rebasing, I have a couple thoughts.
>
> 1) I think it only really makes sense to make a public annotation to a
> commit that is public, and once a commit is public it should not be
> rebased.
Again, do not limit your design by your expectations. People already talk
about having cover letters for their patch series as notes, and Pasky
seems to discuss tracking explicit renames with notes when he does not
play Go, instead of maintaining repo.or.cz and git.or.cz.
> 2) We could also annotate the commit's tree instead of the commit.
> That would make it somewhat resistant to rebases, cherry-picks and
> amends.
To the contrary. When I rebase, the tree _does_ change, otherwise I would
have rebased onto something that had the same original tree as my
rebase-base to begin with, which would make the rebase rather pointless.
> > Some thoughts from me on naming issues:
> > http://article.gmane.org/gmane.comp.version-control.git/100402
>
> On naming. I strongly support a ref/notes/sha1/sha1 approach.
I think you meant refs/notes:<first byte in hex>/<rest of bytes>/<some
arbitrary SHA-1>?
I am rather supporting refs/nots:<first byte in hex>/<rest of bytes> being
either a blob, or a tree containing human readable tags, such as "bugfix"
or "review" or some such.
> If having a type to the note is important, then perhaps the first line
> of a note could be considered a type or a set of "tags".
That would be horrible! Just to know if you need to unpack the blob,
you'd have to unpack it!
Hth,
Dscho
^ permalink raw reply
* [EGIT PATCH 0/2] *** SUBJECT HERE ***
From: Robin Rosenberg @ 2008-12-17 0:07 UTC (permalink / raw)
To: spearce; +Cc: git, Robin Rosenberg
The few plugin unit tests we have is a sad story. Cheer up a bit.
Robin Rosenberg (2):
Revert "Fix commit id in egit test
T0001_ConnectProviderOperationTest"
Fixed an old failed EGit unit test.
.../egit/core/internal/mapping/T0002_history.java | 5 ++---
.../op/T0001_ConnectProviderOperationTest.java | 3 ++-
2 files changed, 4 insertions(+), 4 deletions(-)
^ permalink raw reply
* [EGIT PATCH 2/2] Fixed an old failed EGit unit test.
From: Robin Rosenberg @ 2008-12-17 0:07 UTC (permalink / raw)
To: spearce; +Cc: git, Robin Rosenberg
In-Reply-To: <1229472439-24104-2-git-send-email-robin.rosenberg@dewire.com>
The index was dropped from the history with Shawns revision walker.
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
.../egit/core/internal/mapping/T0002_history.java | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/org.spearce.egit.core.test/src/org/spearce/egit/core/internal/mapping/T0002_history.java b/org.spearce.egit.core.test/src/org/spearce/egit/core/internal/mapping/T0002_history.java
index b540e10..71f5cc5 100644
--- a/org.spearce.egit.core.test/src/org/spearce/egit/core/internal/mapping/T0002_history.java
+++ b/org.spearce.egit.core.test/src/org/spearce/egit/core/internal/mapping/T0002_history.java
@@ -98,8 +98,7 @@ public void testShallowHistory() {
IFileHistoryProvider fileHistoryProvider = provider.getFileHistoryProvider();
IFileHistory fileHistory = fileHistoryProvider.getFileHistoryFor(project.getProject().getWorkspace().getRoot().findMember("Project-1/A.txt"), IFileHistoryProvider.SINGLE_LINE_OF_DESCENT, new NullProgressMonitor());
IFileRevision[] fileRevisions = fileHistory.getFileRevisions();
- assertEquals(2, fileRevisions.length);
- assertEquals("Index", fileRevisions[0].getContentIdentifier());
- assertEquals("6dd8f0b51204fa24a01734971947847549ec4ba8", fileRevisions[1].getContentIdentifier());
+ assertEquals(1, fileRevisions.length);
+ assertEquals("6dd8f0b51204fa24a01734971947847549ec4ba8", fileRevisions[0].getContentIdentifier());
}
}
--
1.6.0.3.640.g6331a
^ permalink raw reply related
* [EGIT PATCH 1/2] Revert "Fix commit id in egit test T0001_ConnectProviderOperationTest"
From: Robin Rosenberg @ 2008-12-17 0:07 UTC (permalink / raw)
To: spearce; +Cc: git, Robin Rosenberg
In-Reply-To: <1229472439-24104-1-git-send-email-robin.rosenberg@dewire.com>
This reverts commit 61133091d5f22398828b350ff772165e9945db8a.
Bisect says this is the commit that failed, which is odd. Bad QA.
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
.../op/T0001_ConnectProviderOperationTest.java | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/org.spearce.egit.core.test/src/org/spearce/egit/core/op/T0001_ConnectProviderOperationTest.java b/org.spearce.egit.core.test/src/org/spearce/egit/core/op/T0001_ConnectProviderOperationTest.java
index 0ce2d7f..aae1ef4 100644
--- a/org.spearce.egit.core.test/src/org/spearce/egit/core/op/T0001_ConnectProviderOperationTest.java
+++ b/org.spearce.egit.core.test/src/org/spearce/egit/core/op/T0001_ConnectProviderOperationTest.java
@@ -99,8 +99,9 @@ assertTrue("tree missing", new File(gitDir,
"objects/08/ccc3d91a14d337a45f355d3d63bd97fd5e4db9").exists());
assertTrue("tree missing", new File(gitDir,
"objects/9d/aeec817090098f05eeca858e3a552d78b0a346").exists());
+
assertTrue("commit missing", new File(gitDir,
- "objects/09/6f1a84091b90b6d9fb12f95848da69496305c1").exists());
+ "objects/45/df73fd9abbc2c61620c036948b1157e4d21253").exists());
ConnectProviderOperation operation = new ConnectProviderOperation(
project.getProject(), null);
--
1.6.0.3.640.g6331a
^ permalink raw reply related
* rebasing commits that have notes, was Re: Git Notes idea.
From: Johannes Schindelin @ 2008-12-17 0:12 UTC (permalink / raw)
To: Jeff King; +Cc: Govind Salinas, Git Mailing List
In-Reply-To: <20081216085108.GA3031@coredump.intra.peff.net>
Hi,
On Tue, 16 Dec 2008, Jeff King wrote:
> Some discussion of the interaction of notes and rebase:
> http://thread.gmane.org/gmane.comp.version-control.git/100533
Oh, I misinterpreted that label... of course you can track rebases in
notes, but some issue that we did not look into yet (I think) is the issue
that you can cherry-pick and rebase commits and lose notes in the process.
It seems that the notes idea is not that unintrusive as I thought...
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Documentation: fix description for enabling hooks
From: Markus Heidelberg @ 2008-12-17 2:59 UTC (permalink / raw)
To: gitster; +Cc: git
Since f98f8cb (Ship sample hooks with .sample suffix, 2008-06-24) hooks
are not enabled by making them executable anymore, but by removing the
'.sample' suffix from the filename.
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
---
Documentation/gitrepository-layout.txt | 3 ++-
Documentation/glossary-content.txt | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/Documentation/gitrepository-layout.txt b/Documentation/gitrepository-layout.txt
index a969b3f..1befca9 100644
--- a/Documentation/gitrepository-layout.txt
+++ b/Documentation/gitrepository-layout.txt
@@ -134,7 +134,8 @@ hooks::
Hooks are customization scripts used by various git
commands. A handful of sample hooks are installed when
'git-init' is run, but all of them are disabled by
- default. To enable, they need to be made executable.
+ default. To enable, the `.sample` suffix has to be
+ removed from the filename by renaming.
Read linkgit:githooks[5] for more details about
each hook.
diff --git a/Documentation/glossary-content.txt b/Documentation/glossary-content.txt
index 9b4a4f4..9afca75 100644
--- a/Documentation/glossary-content.txt
+++ b/Documentation/glossary-content.txt
@@ -183,7 +183,8 @@ to point at the new commit.
and potentially aborted, and allow for a post-notification after the
operation is done. The hook scripts are found in the
`$GIT_DIR/hooks/` directory, and are enabled by simply
- making them executable.
+ removing the `.sample` suffix from the filename. In earlier versions
+ of git you had to make them executable.
[[def_index]]index::
A collection of files with stat information, whose contents are stored
--
1.6.1.rc3.23.gaf48b
^ permalink raw reply related
* [PATCH] doc/git-reset: add reference to git-stash
From: Markus Heidelberg @ 2008-12-17 2:59 UTC (permalink / raw)
To: gitster; +Cc: git
The "Interrupted workflow" situation is a good example for using
git-stash.
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
---
Documentation/git-reset.txt | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt
index 52aab5e..29156f6 100644
--- a/Documentation/git-reset.txt
+++ b/Documentation/git-reset.txt
@@ -177,6 +177,8 @@ $ git reset <3>
<3> At this point the index file still has all the WIP changes you
committed as 'snapshot WIP'. This updates the index to show your
WIP files as uncommitted.
++
+See also linkgit:git-stash[1].
Reset a single file in the index::
+
--
1.6.1.rc3.23.gaf48b
^ permalink raw reply related
* Re: [PATCH] doc/git-reset: add reference to git-stash
From: Miklos Vajna @ 2008-12-17 4:11 UTC (permalink / raw)
To: Markus Heidelberg; +Cc: gitster, git
In-Reply-To: <200812170359.36253.markus.heidelberg@web.de>
[-- Attachment #1: Type: text/plain, Size: 848 bytes --]
On Wed, Dec 17, 2008 at 03:59:36AM +0100, Markus Heidelberg <markus.heidelberg@web.de> wrote:
> ++
> +See also linkgit:git-stash[1].
Manpages have a dedicated "SEE-ALSO" section. What about this?
(See Documentation/git-commit.txt for an example.)
---
Documentation/git-reset.txt | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt
index 52aab5e..e7ddc43 100644
--- a/Documentation/git-reset.txt
+++ b/Documentation/git-reset.txt
@@ -195,6 +195,10 @@ $ git add frotz.c <3>
<2> This commits all other changes in the index.
<3> Adds the file to the index again.
+SEE ALSO
+--------
+linkgit:git-stash[1]
+
Author
------
Written by Junio C Hamano <gitster@pobox.com> and Linus Torvalds <torvalds@osdl.org>
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply related
* Re: [PATCH] Documentation: fix description for enabling hooks
From: Miklos Vajna @ 2008-12-17 4:13 UTC (permalink / raw)
To: Markus Heidelberg; +Cc: gitster, git
In-Reply-To: <200812170359.24109.markus.heidelberg@web.de>
[-- Attachment #1: Type: text/plain, Size: 449 bytes --]
On Wed, Dec 17, 2008 at 03:59:23AM +0100, Markus Heidelberg <markus.heidelberg@web.de> wrote:
> Since f98f8cb (Ship sample hooks with .sample suffix, 2008-06-24) hooks
> are not enabled by making them executable anymore, but by removing the
> '.sample' suffix from the filename.
This is true, but having the executable bit is necessary as well. I
think it would be better to just append this requirement instead of
replacing the old one with this.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Strange untracked file behaviour
From: Johannes Schindelin @ 2008-12-17 5:09 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <20081216232452.GV5691@genesis.frugalware.org>
Hi,
On Wed, 17 Dec 2008, Miklos Vajna wrote:
> Here is a copy of the udev repo I cloned some time ago:
>
> http://frugalware.org/~vmiklos/files/udev.tar.bz2
>
> I did not modify it, so I thought a simple 'git pull' can update it.
>
> $ git pull
> Updating 661a0be..b6626d0
> error: Untracked working tree file 'test/sys/class/misc/rtc/dev' would
> be removed by merge.
I just spent three hours narrowing it down to this test case (but now I
have to catch 3 hours of sleep):
-- snipsnap --
[PATCH] Miklos' testcase
Even if we would not handle symlink/directory conflicts gracefully (which
we do, though), those conflicts should not affect unchanged files at all,
especially not claiming that they are untracked.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
t/t1008-read-tree-sd.sh | 39 +++++++++++++++++++++++++++++++++++++++
1 files changed, 39 insertions(+), 0 deletions(-)
create mode 100644 t/t1008-read-tree-sd.sh
diff --git a/t/t1008-read-tree-sd.sh b/t/t1008-read-tree-sd.sh
new file mode 100644
index 0000000..4d74430
--- /dev/null
+++ b/t/t1008-read-tree-sd.sh
@@ -0,0 +1,39 @@
+#!/bin/sh
+#
+# Copyright (c) 2008 Johannes E. Schindelin
+#
+
+test_description='symlink/directory conflict'
+
+. ./test-lib.sh
+
+test_expect_success 'setup' '
+
+ mkdir -p alpha/beta/gamma &&
+ ln -s delta alpha/beta/gamma/epsilon &&
+ mkdir -p alpha/beta/theta &&
+ ln -s zeta alpha/beta/theta/eta &&
+ mkdir -p iota/kappa/lambda/ &&
+ : > iota/kappa/lambda/mu &&
+ git add . &&
+ test_tick &&
+ git commit -m initial &&
+
+ git rm -r alpha/beta/gamma &&
+ ln -s nu alpha/beta/gamma &&
+ git rm -r alpha/beta/theta &&
+ ln -s xi alpha/beta/theta &&
+ git add . &&
+ test_tick &&
+ git commit -m 2nd
+
+'
+
+test_expect_failure 'read-tree -u -m handles symlinks gracefully' '
+
+ git checkout -b side HEAD^ &&
+ git read-tree -u -m master
+
+'
+
+test_done
--
1.6.0.4.1189.g8876f
^ permalink raw reply related
* white spaces in a patch
From: Mark Ryden @ 2008-12-17 7:31 UTC (permalink / raw)
To: git
Hello,
It occurred to me that I prepared some patch for a git tree, and
then when testing git-apply on it (on the original tree) I saw
some "white spaces" errors.
I know that I can run:
"git --whitespace=fix apply" on my patch and than create the patch
again ; in this way it will be created without white spaces.
Suppose I create a patch file (let's say : patch.txt)
1) Is there a way to check whether there are white spaces in this
file without running git-apply?
2) Is there a way to get some messages about that there are white spaces
when creating a git patch?
Regards,
Mark
^ permalink raw reply
* Re: how to work in hirarchical git model?
From: Johannes Sixt @ 2008-12-17 7:32 UTC (permalink / raw)
To: Gili Pearl; +Cc: git
In-Reply-To: <703400.93370.qm@web112210.mail.gq1.yahoo.com>
Gili Pearl schrieb:
> Here is one problem I saw when trying to work in the three-level model.
> At some point, I had the following setup:
>
> top-level : A----B----C----D
> \
> \
> mid-level1: K----L----M
> \
> \
> low-level1: X----Y
>
> The maintainer of mid-level1 has decided that commits K L M are ready to be
> merged into the top-level repo. So he rebased on top-level before asking 'please
> pull', but after that the low-level was not able to rebase on the mid-level
> any more.
In this model, the mid-level1 maintainer should *not* rebase against
top-level. Rather, he should ask the top-level maintainer to *merge* K-L-M.
> So what is the right working flow for us?
The only ones who should be allowed to rebase are developers at the lowest
level. Everyone else should only pull or merge.
-- Hannes
^ permalink raw reply
* Re: white spaces in a patch
From: Junio C Hamano @ 2008-12-17 7:34 UTC (permalink / raw)
To: Mark Ryden; +Cc: git
In-Reply-To: <dac45060812162331k19272488r4e95e0555e7a6db9@mail.gmail.com>
"Mark Ryden" <markryde@gmail.com> writes:
> 1) Is there a way to check whether there are white spaces in this
> file without running git-apply?
"sed -n -e '/^+.*[ ]$/p' patch.txt" perhaps?
> 2) Is there a way to get some messages about that there are white spaces
> when creating a git patch?
Doesn't "git diff" highlight whitespace errors? That way, you can catch
errors before you make a commit that has them.
^ permalink raw reply
* bug#1571: only one word about git in (info "(emacs)Version Control")
From: jidanni @ 2008-12-15 16:15 UTC (permalink / raw)
To: bug-gnu-emacs
In (info "(emacs)Version Control") there is literally only one word
about git, on (info "(emacs)Customizing VC"). Somebody who has used
git for more than a few minutes should add something.
emacs-version "22.2.1"
(I added X-Debbugs-CC: git@vger.kernel.org (lest I use a real CC
causing bug number escalation), but it seems the git list filters
things coming in from the side.)
^ permalink raw reply
* bug#1571: only one word about git in (info "(emacs)Version Control")
From: jidanni @ 2008-12-15 16:15 UTC (permalink / raw)
To: bug-gnu-emacs
In (info "(emacs)Version Control") there is literally only one word
about git, on (info "(emacs)Customizing VC"). Somebody who has used
git for more than a few minutes should add something.
emacs-version "22.2.1"
(I added X-Debbugs-CC: git@vger.kernel.org (lest I use a real CC
causing bug number escalation), but it seems the git list filters
things coming in from the side.)
^ 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