* 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
* Re: [PATCH] Documentation: fix description for enabling hooks
From: Johannes Sixt @ 2008-12-17 7:44 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Markus Heidelberg, gitster, git
In-Reply-To: <20081217041312.GZ5691@genesis.frugalware.org>
Miklos Vajna schrieb:
> 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.
Markus's proposed new wording is correct because the .sample hooks *are*
already executable.
-- Hannes
^ permalink raw reply
* Re: [PATCH] gitweb: unify boolean feature subroutines
From: Petr Baudis @ 2008-12-17 8:10 UTC (permalink / raw)
To: Matt Kraai; +Cc: Junio C Hamano, git, Jakub Narebski
In-Reply-To: <20081216142357.GF4529@ftbfs.org>
Hi,
On Tue, Dec 16, 2008 at 06:23:57AM -0800, Matt Kraai wrote:
> On Tue, Dec 16, 2008 at 01:03:03AM -0800, Junio C Hamano wrote:
> > But a change to the function signature of feature subroutines is not
> > something I'd like to apply while other series that want to add new
> > features are still cooking. How about doing these two patches as the
> > first thing that goes to 'next' after 1.6.1, and then force other series
> > rebase on top of your change? Alternatively, we could make you wait until
> > other series do settle in 'next' and then apply your change rebased on
> > them, but I think that is probably less optimal.
>
> OK, I'll resubmit the patches on top of 'next' once 1.6.1 is
> released. Thanks for your help,
is it worth keeping them separate? Just a single patch makes more sense
to me, the interface is much nicer in the latter than in the former. :-)
Petr "Pasky" Baudis
^ permalink raw reply
* Re: [PATCH 1/3] gitweb: Move 'lineno' id from link to row element in git_blame
From: Petr Baudis @ 2008-12-17 8:13 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Luben Tuikov
In-Reply-To: <20081209224330.28106.18301.stgit@localhost.localdomain>
On Tue, Dec 09, 2008 at 11:46:16PM +0100, Jakub Narebski wrote:
> Move l<line number> ID from <a> link element inside table row (inside
> cell element for column with line numbers), to encompassing <tr> table
> row element. It was done to make it easier to manipulate result HTML
> with DOM, and to be able write 'blame_incremental' view with the same,
> or nearly the same result.
>
> Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Acked-by: Petr Baudis <pasky@suse.cz>
^ permalink raw reply
* Re: [PATCH 2/3 (edit v2)] gitweb: Cache $parent_commit info in git_blame()
From: Petr Baudis @ 2008-12-17 8:19 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, Nanako Shiraishi, git, Luben Tuikov
In-Reply-To: <200812110133.33124.jnareb@gmail.com>
On Thu, Dec 11, 2008 at 01:33:29AM +0100, Jakub Narebski wrote:
> Luben Tuikov changed 'lineno' link from leading to commit which gave
> current version of given block of lines, to leading to parent of this
> commit in 244a70e (Blame "linenr" link jumps to previous state at
> "orig_lineno"). This made possible data mining using 'blame' view.
>
> The current implementation calls rev-parse once per each blamed line
> to find parent revision of blamed commit, even when the same commit
> appears more than once, which is inefficient.
>
> This patch attempts to mitigate this issue by storing (caching)
> $parent_commit info in %metainfo, which makes gitweb call
> git-rev-parse only once per each unique commit in blame output.
>
>
> In the tables below you can see simple benchmark comparing gitweb
> performance before and after this patch
>
> File | L[1] | C[2] || Time0[3] | Before[4] | After[4]
> ====================================================================
> blob.h | 18 | 4 || 0m1.727s | 0m2.545s | 0m2.474s
> GIT-VERSION-GEN | 42 | 13 || 0m2.165s | 0m2.448s | 0m2.071s
> README | 46 | 6 || 0m1.593s | 0m2.727s | 0m2.242s
> revision.c | 1923 | 121 || 0m2.357s | 0m30.365s | 0m7.028s
> gitweb/gitweb.perl | 6291 | 428 || 0m8.080s | 1m37.244s | 0m20.627s
>
> File | L/C | Before/After
> =========================================
> blob.h | 4.5 | 1.03
> GIT-VERSION-GEN | 3.2 | 1.18
> README | 7.7 | 1.22
> revision.c | 15.9 | 4.32
> gitweb/gitweb.perl | 14.7 | 4.71
>
> As you can see the greater ratio of lines in file to unique commits
> in blame output, the greater gain from the new implementation.
>
> Footnotes:
> ~~~~~~~~~~
> [1] Lines:
> $ wc -l <file>
> [2] Individual commits in blame output:
> $ git blame -p <file> | grep author-time | wc -l
> [3] Time for running "git blame -p" (user time, single run):
> $ time git blame -p <file> >/dev/null
> [4] Time to run gitweb as Perl script from command line:
> $ gitweb-run.sh "p=.git;a=blame;f=<file>" > /dev/null 2>&1
>
> The gitweb-run.sh script includes slightly modified (with adjusted
> pathnames) code from gitweb_run() function from the test script
> t/t9500-gitweb-standalone-no-errors.sh; gitweb config file
> gitweb_config.perl contents (again up to adjusting pathnames; in
> particular $projectroot variable should point to top directory of git
> repository) can be found in the same place.
>
>
> Alternate solutions:
> ~~~~~~~~~~~~~~~~~~~~
> Alternate solution would be to open bidi pipe to "git cat-file
> --batch-check", (like in Git::Repo in gitweb caching by Lea Wiemann),
> feed $long_rev^ to it, and parse its output which has the following
> form:
>
> 926b07e694599d86cec668475071b32147c95034 commit 637
>
> This would mean one call to git-cat-file for the whole 'blame' view,
> instead of one call to git-rev-parse per each unique commit in blame
> output.
>
>
> Yet another solution would be to change use of validate_refname() to
> validate_revision() when checking script parameters (CGI query or
> path_info), with validate_revision being something like the following:
>
> sub validate_revision {
> my $rev = shift;
> return validate_refname(strip_rev_suffixes($rev));
> }
>
> so we don't need to calculate $long_rev^, but can pass "$long_rev^" as
> 'hb' parameter.
>
> This solution has the advantage that it can be easily adapted to
> future incremental blame output.
>
> Acked-by: Luben Tuikov <ltuikov@yahoo.com>
> Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Acked-by: Petr Baudis <pasky@suse.cz>
(though I think the commit message is total overkill for such an obvious
change ;-)
^ permalink raw reply
* Re: [PATCH] gitweb: unify boolean feature subroutines
From: Junio C Hamano @ 2008-12-17 8:20 UTC (permalink / raw)
To: Petr Baudis; +Cc: Matt Kraai, git, Jakub Narebski
In-Reply-To: <20081217081028.GA3640@machine.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Hi,
>
> On Tue, Dec 16, 2008 at 06:23:57AM -0800, Matt Kraai wrote:
>> On Tue, Dec 16, 2008 at 01:03:03AM -0800, Junio C Hamano wrote:
>> > But a change to the function signature of feature subroutines is not
>> > something I'd like to apply while other series that want to add new
>> > features are still cooking. How about doing these two patches as the
>> > first thing that goes to 'next' after 1.6.1, and then force other series
>> > rebase on top of your change? Alternatively, we could make you wait until
>> > other series do settle in 'next' and then apply your change rebased on
>> > them, but I think that is probably less optimal.
>>
>> OK, I'll resubmit the patches on top of 'next' once 1.6.1 is
>> released. Thanks for your help,
>
> is it worth keeping them separate? Just a single patch makes more sense
> to me, the interface is much nicer in the latter than in the former. :-)
I agree.
It should come *first* before other topics that are not in 'master/next'
and change the function signature of feature subs of only existing (read:
in 'master') ones. This will force gb/gitweb-patch (and anybody else's
patch that haven't been submitted, waiting during the -rc period) to be
rebased on top of the updated interface, but that's life.
^ permalink raw reply
* Re: how to work in hirarchical git model?
From: Gili Pearl @ 2008-12-17 8:23 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <4948AB14.8030004@viscovery.net>
----- Original Message ----
> From: Johannes Sixt <j.sixt@viscovery.net>
>
> 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.
>
But what if K-L-M conflict with C-D? The one who should take care about it is
the mid-level1 maintainer (or possibly one of the low-level1 maintainers).
> > 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.
>
I still don't see clearly what happens next in the example above when the low
level developr wants to push X-Y upstream? On which branch should he rebase?
Need he rebase on mid-level (where K-L-M were already merged upstream), or
maybe direclty on the top-level??
Thanks
^ permalink raw reply
* Re: how to work in hirarchical git model?
From: Johan Herland @ 2008-12-17 8:33 UTC (permalink / raw)
To: git; +Cc: Gili Pearl, Johannes Sixt
In-Reply-To: <753177.33978.qm@web112212.mail.gq1.yahoo.com>
On Wednesday 17 December 2008, Gili Pearl wrote:
> ----- Original Message ----
>
> > From: Johannes Sixt <j.sixt@viscovery.net>
> > 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.
>
> But what if K-L-M conflict with C-D? The one who should take care about
> it is the mid-level1 maintainer (or possibly one of the low-level1
> maintainers).
If there is a merge conflict, mid-level1 maintainer will typically merge D
and M into a new merge commit N:
top-level : A----B----C----D
\ \
\ \
mid-level1: K----L----M----N
...and then ask top-level maintainer to merge N (which should have no
conflicts by now). The merge can also be done by low-level1 developer.
> > > 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.
>
> I still don't see clearly what happens next in the example above when the
> low level developr wants to push X-Y upstream? On which branch should he
> rebase? Need he rebase on mid-level (where K-L-M were already
> merged upstream), or maybe direclty on the top-level??
If you're a leaf developer (i.e. allowed to rebase), you should rebase
against your immediate upstream's branch. In this example, that is
mid-level1's branch.
Have fun!
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ 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