* Re: [RFC] origin link for cherry-pick and revert
From: Stephen R. van den Berg @ 2008-09-11 22:56 UTC (permalink / raw)
To: Jeff King; +Cc: Theodore Tso, Jakub Narebski, Linus Torvalds, git
In-Reply-To: <20080911214650.GB3187@coredump.intra.peff.net>
Jeff King wrote:
>On Thu, Sep 11, 2008 at 04:04:53PM -0400, Theodore Tso wrote:
>> > It will be q^..q, and specifically not p^..p, using ^p..p would be
>> > lying. We aim to document the evolvement of the patch in time.
>> > Cherry-pick itself will always ignore the origin links present on the
>> > old commit, it simply creates new ones as if the old ones didn't exist.
>> So if you never pull branch C (where commit q resides), there is no
>> way for you to know that commits p and r are related. How.... not
>> useful.
>But what about workflows in between? When I pull from some developer who
>has added a weak reference to a particular commit SHA1, but I _don't_
>have that commit, my next question "OK, so what was in that commit?".
>What is the mechanism by which I find out more information on that SHA1?
Well, the usual way to fix this is to actually startup fetch and tell it
to try and fetch all the weak links (or just fetch a single hash (the
offending origin link)) from upstream; this is by no means the default
operatingmode of fetch, but I don't see any harm in allowing to fetch
those if one really wants to.
>Using a key that is meaningful to an external database (like a bug
>tracker) means that you can go to that database to look up more
>information.
True. And also a Good Thing, I concur.
--
Sincerely,
Stephen R. van den Berg.
"There are three types of people in the world;
those who can count, and those who can't."
^ permalink raw reply
* Re: Git User's Survey 2008 partial summary, part 5 - other SCM
From: david @ 2008-09-11 22:51 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200809112214.18366.jnareb@gmail.com>
On Thu, 11 Sep 2008, Jakub Narebski wrote:
> A bit suprising for me is high place of Perforce. Another strange
> thing (and a bit alarming) is that MS Visual SourceSafe has higher
> place than Monotone; but that might be caused by different design and
> different target groups of Monotone and Git, which might have caused
> that the communities have almost no overlap; people choose either Git
> or Monotone, one or the other. BitKeeper has also a very low number
> of active users among Git users... but that is not that strange,
> considering history.
I think you are making the wrong assumption here.
someone may use CVS becouse they contribute to a project that is only
availabe via CVS
someone may use Perforce becouse that is the VCS that their company uses
if you do commercial development with windows you are almsot going to be
required to use MS VSS.
you are looking at it from the point of view of 'which VCS would you
select for a new project', but that would be a very different question.
I find it interesting that the number of people who use git and the other
DVCS systems in so small. Is this becouse the 'market share' of those
other systems is small? or becouse people who learn git aren't willing to
put up with other systems (or vice-versa)? or is there some other trend
or tendancy that makes people who select one DVCS more likely to work on
similar projects, so people interested in those types of projects will
generally just see a single DVCS system
David Lang
^ permalink raw reply
* Re: [JGIT PATCH 1/2] Issue 23: Resolve tag^0 as tag^{commit}
From: Robin Rosenberg @ 2008-09-11 22:47 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: Shawn O. Pearce, git
In-Reply-To: <20080911213927.GA20238@diku.dk>
torsdagen den 11 september 2008 23.39.27 skrev Jonas Fonseca:
> Repository.resolve("tag^0") failed with "not a commit". Fix it and add a
> test case for it.
It seems this case is not *that* special. It is tag^N == tag^{commit}^N
Same for tag~N == tag^{commit}~N-
My fault, i guess, but it would be nice of you fixed it while you are at it.
Second, the testcase in the second patch fails on my machine.
testDerefTaggedTagTree(org.spearce.jgit.lib.T0008_testparserev)
junit.framework.ComparisonFailure: expected:<[269e1253bad5c247c6bde37aa48ae1e03138206c]> but was:<[be83157b4ffe650d728ba4f98ad47b623b0d0c20]>
at junit.framework.Assert.assertEquals(Assert.java:81)
at junit.framework.Assert.assertEquals(Assert.java:87)
at org.spearce.jgit.lib.T0008_testparserev.testDerefTaggedTagTree(T0008_testparserev.java:123)
-- robin
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Stephen R. van den Berg @ 2008-09-11 22:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, Jakub Narebski, Linus Torvalds, git
In-Reply-To: <20080911223203.GA29559@cuci.nl>
Stephen R. van den Berg wrote:
>Junio C Hamano wrote:
>>This is different from the normal "following" in that B is not allowed to
>>pass the blame to its parents (should it be allowed to pass it to its
>>"origin"?), because the _only thing_ cherry-pick did was to transport what
>>B did (relative to A) to the unrelated history that led to X.
>Well, I'd expect:
>a. That B should be able to pass blame onto it's origin.
>b. That B should be able to pass blame onto A (and deeper).
>Let me show another example:
>....-C---D---E---F---G
> . (origin)
> .
> ...---A---B
> . (origin)
> .
> ...---o---X---Y---Z
>Now suppose there is a piece of sourcecode which evolves from C to F,
>then when I dig into G using blame I get something like: CCCFFEGGDDDCC
>(Every letter represents a line in the sourcecode)
>Digging into Z I'd expect to see the following: ZZCCCFFEDDYDCCB
>All this assumes that there were minimal changes to the patch when
>creating B, and also minimal changes to the patch when creating Y.
>I.e. large parts of that code where developed during C, D, E and F, so
>that is what I expect to see; is that illogical?
I'm sorry, you're right, I'm confusing things here. The case I'm describing
here can only happen when you do this:
....-C---D---E---F---G
\...\...\..\ (origin)
.
...---A---B
. (origin)
.
...---o---X---Y---Z
I.e. the first cherry-pick needs to cherry-pick C, D, E *and* F into B,
that will result in four origin fields there.
And yes, that means that:
- blame follows origin links (repeatedly).
- blame does *not* travel to parents of commits found through an origin
link.
Does that mean that blame uses origin fields? Yes, it does, and it has
to check for origin links at every commit it traverses.
--
Sincerely,
Stephen R. van den Berg.
"There are three types of people in the world;
those who can count, and those who can't."
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Stephen R. van den Berg @ 2008-09-11 22:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, Jakub Narebski, Linus Torvalds, git
In-Reply-To: <7vy71ys8a7.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
>I keep hearing "blame" in this discussion, but I do not understand why
>people think blame should _follow_ this "origin" information (in the usual
>sense of "following").
>Suppose you cherry-pick an existing commit from unrelated context:
> ...---A---B
> . (origin)
> .
> ...---o---X---Y---Z
>i.e. on top of X the difference to bring A to B is applied to produce Y,
>and a new development Z is made on top. You start digging from Z.
>Let's see how we would want "origin" get involved. Instead of the above,
>what Y would do would be:
> (1) if the contents (excluding the part Z changed) is different from X,
> instead of taking the blame itself, give the _final_ blame to B.
> (2) the remainder is passed to X as usual.
Sounds reasonable.
>This is different from the normal "following" in that B is not allowed to
>pass the blame to its parents (should it be allowed to pass it to its
>"origin"?), because the _only thing_ cherry-pick did was to transport what
>B did (relative to A) to the unrelated history that led to X.
Well, I'd expect:
a. That B should be able to pass blame onto it's origin.
b. That B should be able to pass blame onto A (and deeper).
Let me show another example:
...-C---D---E---F---G
. (origin)
.
...---A---B
. (origin)
.
...---o---X---Y---Z
Now suppose there is a piece of sourcecode which evolves from C to F,
then when I dig into G using blame I get something like: CCCFFEGGDDDCC
(Every letter represents a line in the sourcecode)
Digging into Z I'd expect to see the following: ZZCCCFFEDDYDCCB
All this assumes that there were minimal changes to the patch when
creating B, and also minimal changes to the patch when creating Y.
I.e. large parts of that code where developed during C, D, E and F, so
that is what I expect to see; is that illogical?
--
Sincerely,
Stephen R. van den Berg.
"There are three types of people in the world;
those who can count, and those who can't."
^ permalink raw reply
* Re: RFC: perhaps a "new file" should not be deleted by "git reset --hard"
From: Eric Raible @ 2008-09-11 22:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd4jas6x8.fsf@gitster.siamese.dyndns.org>
On Thu, Sep 11, 2008 at 2:34 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Eric Raible <raible@gmail.com> writes:
>
>> But can you see a downside to "git reset --hard" treating newly
>> added files as "git reset"?
>
> Of course. The --hard option is called --hard without inviting short
> option for a reason.
>
> [various good reasons snipped]
Thanks for the definitive response. I suppose that I had been getting
rather cavalier about --hard. Now my expectations are more aligned with
reality.
And that reality makes perfect sense, it's just a bit harsh when hundreds
of important files get obliterated!
- Eric
^ permalink raw reply
* Re: Git User's Survey 2008 partial summary, part 5 - other SCM
From: Jakub Narebski @ 2008-09-11 22:05 UTC (permalink / raw)
To: Joshua Jensen; +Cc: Anatol Pomozov, git, Dana L. How
In-Reply-To: <48C98F92.40903@workspacewhiz.com>
Joshua Jensen wrote:
> Anatol Pomozov wrote:
>> Jakub Narebski wrote:
>>>
>>> A bit suprising for me is high place of Perforce.
>>>
>> Some huge companies use Perforce. A good example here is Google. But
>> at the same time there are a lot of Google employees who interested in
>> git. Especially after Linus TechTalk. Googlers created a wrapper for
>> perforce that tries to bring git to everyone and ~300 people actively
>> use it.
>>
> Many game companies use Perforce, as it has pretty good handling of
> gigabytes upon gigabytes of art content. This is one area where a
> centralized repository trumps the distributed ones with full history.
> The checkout tree for one product I worked on was 70 gigabytes, and I
> still mapped out a large number of files. You can imagine how that
> becomes too unwieldy to have all history locally.
Dana How (Cc-ed) worked on better support in Git for very large and
not well compressed files (and usually with short history). Her
solution was to add support to git to limit size of blobs which
entered packs (files/blobs of size larger than given limit were
left as loose objects), and share those loose objects using network
filesystem. You can search git mailing list to find exact details
of this. IIRC mentioned patches were not accepted; instead there was
proposed a solution where problematic blobs of very large files were
packed into separate kept pack, and this kept pack (or packs, each
containing single blob) were shared using some network filesystem
(network drive).
In addition to that in Documentation/RelNotes-1.5.3 we have:
- "pack-objects" honors "delta" attribute set in
.gitattributes. It does not attempt to deltify blobs that
come from paths with delta attribute set to false.
(but as far as I can see this attribute is otherwise undocumented).
This can also help performance for a repository with very large files.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: What's in git.git (Sep 2008, #02; Wed, 10)
From: Junio C Hamano @ 2008-09-11 22:02 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <48C8E061.5030904@fastmail.fm>
Michael J Gruber <michaeljgruber+gmane@fastmail.fm> writes:
> I think the cleanest approach would consist in introducing another
> linkgit macro (for everything linkgit:git-) which ouputs dashed resp.
> dashless forms for docbook (i.e. man) resp. html targets. I'll cook up a
> POC if noone keeps me from doing so ;)
I personally think the links are Ok to be left as they are in git-foo form
but if there is a good way to persuade manual viewers to display "git foo"
and still follow "man git-foo", that would be great.
Names of the programs in "git-foo" form in the plain text, unless they are
the server side programs, should be updated to say "git foo"
(cf. http://thread.gmane.org/gmane.comp.version-control.git/95436/focus=95443)
^ permalink raw reply
* Re: Git User's Survey 2008 partial summary, part 5 - other SCM
From: Jeff King @ 2008-09-11 21:54 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200809112214.18366.jnareb@gmail.com>
On Thu, Sep 11, 2008 at 10:14:17PM +0200, Jakub Narebski wrote:
> SCM | Never | Used it | Still use
> --------------------------------------------------------------
[...]
> CVS | 12% (242) | 62% (1277) | 13% (260) 1
I like to think of this as 1017 monitors that we have saved from getting
punched in frustration.
> 25) How do you publish/propagate your changes?
> (Choice - Multiple answers)
>
> ======================================
> method | using it
> --------------------------------------
> push | 91% (1740)
Obviously a quite popular choice. I wonder if this could be broken down
more in next year's survey:
- push into my public repo, interested people pull
- push into central repo
-Peff
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Jeff King @ 2008-09-11 21:46 UTC (permalink / raw)
To: Theodore Tso; +Cc: Stephen R. van den Berg, Jakub Narebski, Linus Torvalds, git
In-Reply-To: <20080911200452.GM5082@mit.edu>
On Thu, Sep 11, 2008 at 04:04:53PM -0400, Theodore Tso wrote:
> > It will be q^..q, and specifically not p^..p, using ^p..p would be
> > lying. We aim to document the evolvement of the patch in time.
> > Cherry-pick itself will always ignore the origin links present on the
> > old commit, it simply creates new ones as if the old ones didn't exist.
>
> So if you never pull branch C (where commit q resides), there is no
> way for you to know that commits p and r are related. How.... not
> useful.
That is a good point. Stephen has explained his workflow, and I can see
why he wants to reference the cherry-picked commits, and how he thinks
that the referenced commits will always be available in that workflow.
And obviously in Linus's workflow such references are basically useless,
and they should just not be generated.
But what about workflows in between? When I pull from some developer who
has added a weak reference to a particular commit SHA1, but I _don't_
have that commit, my next question "OK, so what was in that commit?".
What is the mechanism by which I find out more information on that SHA1?
Using a key that is meaningful to an external database (like a bug
tracker) means that you can go to that database to look up more
information.
-Peff
^ permalink raw reply
* [JGIT PATCH 2/2] Add test for resolving "tag^{tree}" where "tag" points to a tag
From: Jonas Fonseca @ 2008-09-11 21:41 UTC (permalink / raw)
To: Robin Rosenberg, Shawn O. Pearce; +Cc: git
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
.../spearce/jgit/test/resources/create-second-pack | 4 ++++
...ck-9c51502a527e1cc8ad4016629730bd1b90145dd6.idx | Bin 0 -> 1100 bytes
...k-9c51502a527e1cc8ad4016629730bd1b90145dd6.pack | Bin 0 -> 167 bytes
.../org/spearce/jgit/test/resources/packed-refs | 2 ++
.../org/spearce/jgit/lib/RepositoryTestCase.java | 1 +
.../org/spearce/jgit/lib/T0008_testparserev.java | 7 ++++++-
6 files changed, 13 insertions(+), 1 deletions(-)
create mode 100644 org.spearce.jgit.test/tst-rsrc/org/spearce/jgit/test/resources/pack-9c51502a527e1cc8ad4016629730bd1b90145dd6.idx
create mode 100644 org.spearce.jgit.test/tst-rsrc/org/spearce/jgit/test/resources/pack-9c51502a527e1cc8ad4016629730bd1b90145dd6.pack
diff --git a/org.spearce.jgit.test/tst-rsrc/org/spearce/jgit/test/resources/create-second-pack b/org.spearce.jgit.test/tst-rsrc/org/spearce/jgit/test/resources/create-second-pack
index 03f83dc..ea02240 100755
--- a/org.spearce.jgit.test/tst-rsrc/org/spearce/jgit/test/resources/create-second-pack
+++ b/org.spearce.jgit.test/tst-rsrc/org/spearce/jgit/test/resources/create-second-pack
@@ -130,6 +130,10 @@ git tag -a -m "An annotated tag" B a^
git repack -d
+git tag -a -m "An annotated tag tagging a tag" C B
+
+git repack -d
+
git pack-refs --all
diff --git a/org.spearce.jgit.test/tst-rsrc/org/spearce/jgit/test/resources/pack-9c51502a527e1cc8ad4016629730bd1b90145dd6.idx b/org.spearce.jgit.test/tst-rsrc/org/spearce/jgit/test/resources/pack-9c51502a527e1cc8ad4016629730bd1b90145dd6.idx
new file mode 100644
index 0000000000000000000000000000000000000000..8405f4c6ec64f8519e17e69702bc35950e128cb6
GIT binary patch
literal 1100
zcmexg;-AdGz`z8=qhK@yMq&ss0zEzA@xEr!YX5(!yhYthes*1{PO|3ZQBbm9xd9k9
wJXUTS*|zl0x>0Br=esNKxZcZ0w+|WWZnu)?y}XifT9^3ql@C8^Ry^GZ0BtNH4FCWD
literal 0
HcmV?d00001
diff --git a/org.spearce.jgit.test/tst-rsrc/org/spearce/jgit/test/resources/pack-9c51502a527e1cc8ad4016629730bd1b90145dd6.pack b/org.spearce.jgit.test/tst-rsrc/org/spearce/jgit/test/resources/pack-9c51502a527e1cc8ad4016629730bd1b90145dd6.pack
new file mode 100644
index 0000000000000000000000000000000000000000..14fa6c4d3abbd372b093f78dc43fe51fa19b7b70
GIT binary patch
literal 167
zcmV;Y09gM}K|@Ob000620005U33!|xj6n**Fc1LmdBuLfvfEU%0TGK|&<AYNB`P*4
zC4&Cm#={JAni8HGE0A*sMn>r^ah%wPAVcK9j_oiYX^(#I(3<*P6sjb%0hi{aD~xc1
z>%FXSl<wWtt<L(9d3k9U%X|VN>OEPq7Ix?mjTtjY&ZSD#sr?%1krT-O{sZeZEQmTr
Vu?Dn{n%HqRUQN1g$1dsO+rk;dPBs7l
literal 0
HcmV?d00001
diff --git a/org.spearce.jgit.test/tst-rsrc/org/spearce/jgit/test/resources/packed-refs b/org.spearce.jgit.test/tst-rsrc/org/spearce/jgit/test/resources/packed-refs
index f67a3ef..fc280c7 100644
--- a/org.spearce.jgit.test/tst-rsrc/org/spearce/jgit/test/resources/packed-refs
+++ b/org.spearce.jgit.test/tst-rsrc/org/spearce/jgit/test/resources/packed-refs
@@ -9,5 +9,7 @@ d86a2aada2f5e7ccf6f11880bfb9ab404e8a8864 refs/heads/pa
6db9c2ebf75590eef973081736730a9ea169a0c4 refs/tags/A
17768080a2318cd89bba4c8b87834401e2095703 refs/tags/B
^d86a2aada2f5e7ccf6f11880bfb9ab404e8a8864
+be83157b4ffe650d728ba4f98ad47b623b0d0c20 refs/tags/C
+^d86a2aada2f5e7ccf6f11880bfb9ab404e8a8864
8bbde7aacf771a9afb6992434f1ae413e010c6d8 refs/tags/spearce-gpg-pub
^fd608fbe625a2b456d9f15c2b1dc41f252057dd7
diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/RepositoryTestCase.java b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/RepositoryTestCase.java
index 270b90a..b40d7b1 100644
--- a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/RepositoryTestCase.java
+++ b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/RepositoryTestCase.java
@@ -141,6 +141,7 @@ public void run() {
"pack-34be9032ac282b11fa9babdc2b2a93ca996c9c2f",
"pack-df2982f284bbabb6bdb59ee3fcc6eb0983e20371",
"pack-9fb5b411fe6dfa89cc2e6b89d2bd8e5de02b5745",
+ "pack-9c51502a527e1cc8ad4016629730bd1b90145dd6",
"pack-e6d07037cbcf13376308a0a995d1fa48f8f76aaa"
};
final File packDir = new File(db.getObjectsDirectory(), "pack");
diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/T0008_testparserev.java b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/T0008_testparserev.java
index 3457574..2a1a4ad 100644
--- a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/T0008_testparserev.java
+++ b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/T0008_testparserev.java
@@ -116,10 +116,15 @@ public void testDerefTagIssue23() throws IOException {
assertEquals("d86a2aada2f5e7ccf6f11880bfb9ab404e8a8864",db.resolve("refs/tags/B^0").name());
}
+ public void testDerefTaggedTagTree() throws IOException {
+ assertEquals("269e1253bad5c247c6bde37aa48ae1e03138206c",db.resolve("refs/tags/C").name());
+ assertEquals("d86a2aada2f5e7ccf6f11880bfb9ab404e8a8864",db.resolve("refs/tags/C^{commit}").name());
+ assertEquals("856ec208ae6cadac25a6d74f19b12bb27a24fe24",db.resolve("refs/tags/C^{tree}").name());
+ }
+
public void testDerefBlob() throws IOException {
assertEquals("fd608fbe625a2b456d9f15c2b1dc41f252057dd7",db.resolve("fd608fbe625a2b456d9f15c2b1dc41f252057dd7^{}").name());
assertEquals("fd608fbe625a2b456d9f15c2b1dc41f252057dd7",db.resolve("fd608fbe625a2b456d9f15c2b1dc41f252057dd7^{blob}").name());
}
- // TODO: ^{tree} for a tag pointing to a tag
}
--
1.6.0.336.ga07ba
--
Jonas Fonseca
^ permalink raw reply related
* [JGIT PATCH 1/2] Issue 23: Resolve tag^0 as tag^{commit}
From: Jonas Fonseca @ 2008-09-11 21:39 UTC (permalink / raw)
To: Robin Rosenberg, Shawn O. Pearce; +Cc: git
Repository.resolve("tag^0") failed with "not a commit". Fix it and add a
test case for it.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
.../org/spearce/jgit/lib/T0008_testparserev.java | 9 ++++++++-
.../src/org/spearce/jgit/lib/Repository.java | 5 +++++
2 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/T0008_testparserev.java b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/T0008_testparserev.java
index 8883b8b..3457574 100644
--- a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/T0008_testparserev.java
+++ b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/T0008_testparserev.java
@@ -109,10 +109,17 @@ public void testDerefTag() throws IOException {
assertEquals("fd608fbe625a2b456d9f15c2b1dc41f252057dd7",db.resolve("spearce-gpg-pub^{blob}").name());
}
+ public void testDerefTagIssue23() throws IOException {
+ assertEquals("17768080a2318cd89bba4c8b87834401e2095703",db.resolve("refs/tags/B").name());
+ assertEquals("d86a2aada2f5e7ccf6f11880bfb9ab404e8a8864",db.resolve("refs/tags/B^{commit}").name());
+ // The special tag^0 == tag^{commit} rule
+ assertEquals("d86a2aada2f5e7ccf6f11880bfb9ab404e8a8864",db.resolve("refs/tags/B^0").name());
+ }
+
public void testDerefBlob() throws IOException {
assertEquals("fd608fbe625a2b456d9f15c2b1dc41f252057dd7",db.resolve("fd608fbe625a2b456d9f15c2b1dc41f252057dd7^{}").name());
assertEquals("fd608fbe625a2b456d9f15c2b1dc41f252057dd7",db.resolve("fd608fbe625a2b456d9f15c2b1dc41f252057dd7^{blob}").name());
}
-
+
// TODO: ^{tree} for a tag pointing to a tag
}
diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java b/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
index b27c23d..260a39d 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
@@ -562,6 +562,11 @@ public ObjectId resolve(final String revstr) throws IOException {
case '9':
int j;
ref = mapObject(refId, null);
+ if (ref instanceof Tag && rev[i + 1] == '0') {
+ Tag tag = (Tag)ref;
+ refId = tag.getObjId();
+ ref = mapObject(refId, null);
+ }
if (!(ref instanceof Commit))
throw new IncorrectObjectTypeException(refId, Constants.TYPE_COMMIT);
for (j=i+1; j<rev.length; ++j) {
--
1.6.0.336.ga07ba
--
Jonas Fonseca
^ permalink raw reply related
* Re: RFC: perhaps a "new file" should not be deleted by "git reset --hard"
From: Junio C Hamano @ 2008-09-11 21:34 UTC (permalink / raw)
To: Eric Raible; +Cc: git
In-Reply-To: <loom.20080911T204256-821@post.gmane.org>
Eric Raible <raible@gmail.com> writes:
> Yes, you have a 100% correct understand of what I'm trying to say.
> But can you see a downside to "git reset --hard" treating newly
> added files as "git reset"?
Of course. The --hard option is called --hard without inviting short
option for a reason.
I am actually somewhat sympathetic to your point, but you would want
"reset --hard" to remove that path when a path does not exist in the HEAD
but in index in other cases. And it is my experience (and I presume you
can guess I have longer git experience than any of you ;-) that far more
often than not that is what is desirable.
Consider:
(1) Your branch does not have "path";
(2) You once thought you want addition of the "path" made in another
branch;
(3) So you did:
$ git checkout another -- path
(4) After more hacking, it turns out that the avenue you chose to reach
your goal, including the addition of the "path", was a mistake, and
you regret having wasted some time. You want to go back to the
current HEAD:
$ git reset --hard
The state after (3) is "HEAD does not have path, index and work tree has
it". In step (4) you would want "git reset --hard" to get rid of such a
path.
And it is no different from the case where you add the path manually to
the index. Both are "you thought you wanted it, but you changed your
mind".
Another example is getting rid of crufts from a conflicted merge. It may
bring in many new paths in your index and the working tree. You would
want a "git reset --hard" to get rid of all of them. Not removing the
paths that are not in HEAD but in index and working tree is far worse in
this case because merging is often done from other people's tree that you
may not be familiar with (i.e. you wanted to study their tree after
merging), so it is harder for you to hand-clean after "reset" if a hard
reset does not do it for you.
^ permalink raw reply
* Re: RFC: perhaps a "new file" should not be deleted by "git reset --hard"
From: Eric Raible @ 2008-09-11 21:24 UTC (permalink / raw)
To: Jeff Whiteside; +Cc: Elijah Newren, Changsheng Jiang, Git Mailing List
In-Reply-To: <3ab397d0809111022m24c81bd9y2520f6be478babd3@mail.gmail.com>
On Thu, Sep 11, 2008 at 10:22 AM, Jeff Whiteside
<jeff.m.whiteside@gmail.com> wrote:
> And if you want to delete all untracked files
> ls | sed s/`git status --index --filenamesonly`//g | rm
> ls | sed s/`git status --commitrepo --filenamesonly`//g | rm
> (I realize those commands don't actually work, but I'm a noob.)
"git clean" (http://www.kernel.org/pub/software/scm/git/docs/git-clean.html)
will delete untracked file.
> So that 'tracked by git' isn't just another ambiguous semantic.
While I can't find where it might be explicitly defined, it does seem
clear that a file/dir is "tracked" as soon as it's added.
My question is why "git reset --hard" can't make a special case for
_newly added_ tracked files. After all, "git status" knows that they're
"new files", and "git reset --hard" could realize that wiping them off
the face of the earth isn't the most helpful thing possible.
- Eric
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Junio C Hamano @ 2008-09-11 21:05 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Stephen R. van den Berg, Jakub Narebski, Linus Torvalds, git
In-Reply-To: <alpine.LFD.1.10.0809111222170.23787@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> Still, in your case, you probably won't get rid of your stable branches,
> hence the reachability argument is rather weak for your usage scenario,
> meaning that you could as well have that info in the free form text
> (like cherry-pick -x), and even generate a special graft file from that
> locally for visualization/blame purposes. Sure the indirection will add
> some overhead, but I doubt it'll be measurable.
I keep hearing "blame" in this discussion, but I do not understand why
people think blame should _follow_ this "origin" information (in the usual
sense of "following").
Suppose you cherry-pick an existing commit from unrelated context:
...---A---B
. (origin)
.
...---o---X---Y---Z
i.e. on top of X the difference to bring A to B is applied to produce Y,
and a new development Z is made on top. You start digging from Z.
Without any "origin", here is how blame works:
* What Z did is blamed on Z; what Z did not change is passed to Y;
* Y needs to:
(1) take responsibility for what it changed; and/or
(2) the remaining contents came from X --- pass the blame to it.
Let's see how we would want "origin" get involved. Instead of the above,
what Y would do would be:
(1) if the contents (excluding the part Z changed) is different from X,
instead of taking the blame itself, give the _final_ blame to B.
(2) the remainder is passed to X as usual.
This is different from the normal "following" in that B is not allowed to
pass the blame to its parents (should it be allowed to pass it to its
"origin"?), because the _only thing_ cherry-pick did was to transport what
B did (relative to A) to the unrelated history that led to X.
IOW, you did not look at the contents outside "diff A..B" when you made
the cherry-pick. There could well be parts of the content that are common
across all of A, Y, X and Z, but as far as Y and Z are concerned, they did
not get any part of that common common content from A (otherwise "origin"
is no different from "parent", but you did not merge).
The output from "origin" aware blame would be identical to the normal
blame, except that lines that usually are labeled with Y are labeled with
B. However:
(1) If you _are_ interested in the line that says Y, you can look at
the commit object Y and see "cherry-pick -x" information to learn
it came from B already; and
(2) More importantly, if you want to dig deeper by peeling the blamed
line (I think gitweb allows this, and probably git-gui), you
shouldn't peel that line blamed on B to start running blame at A.
That would continue digging the history of A, which is wrong when
you are examining the history that led to Z.
So please leave "blame" out of this discussion.
^ permalink raw reply
* Re: Git User's Survey 2008 partial summary, part 5 - other SCM
From: Anatol Pomozov @ 2008-09-11 21:03 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200809112214.18366.jnareb@gmail.com>
Hi,
> A bit suprising for me is high place of Perforce.
Some huge companies use Perforce. A good example here is Google. But
at the same time there are a lot of Google employees who interested in
git. Especially after Linus TechTalk. Googlers created a wrapper for
perforce that tries to bring git to everyone and ~300 people actively
use it.
--
anatol
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Theodore Tso @ 2008-09-11 21:01 UTC (permalink / raw)
To: Stephen R. van den Berg
Cc: Nicolas Pitre, Linus Torvalds, Jakub Narebski, git
In-Reply-To: <20080911195516.GE1451@cuci.nl>
On Thu, Sep 11, 2008 at 09:55:16PM +0200, Stephen R. van den Berg wrote:
> > Having it versionned also
> >means that older git versions will be able to carry that information
> >even if they won't make any use of it, and that also solves the
> >cryptographic issue since that data is part of the top commit SHA1.
>
> It would allow the data to be faked, that is undesirable for "git blame".
Why would this matter? The information is largely
self-authenticating. If a commit claims to have come from some other
cherry-pick, a human taking a quick look at it would know instantly
that this wasn't true. So what's the harm done if some incorrect
information gets introduced? "git blame" is something which is
generally used by humans, not by automated programs.
Also, what's the attack scenario? The person who originally makes the
commit can easily fake the origin link information. They can hack git
to fill on some other commit ID, for example. So what you are
protecting against is someone after the fact adding the annotation
that this commit was related to this other commit. When would this be
a bad thing to do? If they are adding correct information, it's a
good thing. If they add incorrect information, what's the harm they
can as a result of being able to add the incorrect information.
(Noting that if this annotation file is kept under git control, you
can use what ever access controls and/or process controls that verify
that a new cherry-pick --- or a commit claiming to be a cherry-pick
--- is valid and should be accepted into the master git repository for
that project.
- Ted
^ permalink raw reply
* Re: RFC: perhaps a "new file" should not be deleted by "git reset --hard"
From: Eric Raible @ 2008-09-11 20:50 UTC (permalink / raw)
To: git
In-Reply-To: <51419b2c0809101938v30e5a1aflf944027aedc2d900@mail.gmail.com>
Elijah Newren <newren <at> gmail.com> writes:
> Anyway, Eric wasn't really talking about ignoring files, since he was
> explicitly adding them for the next commit. It's just that at some
> point he changed his mind and decided he didn't want to include any of
> the changes he had already made in the next commit, but was surprised
> when git reset --hard deleted the files from both the index and
> working copy instead of just the index. git reset --hard really is
> meant for throwing away unwanted stuff (particularly including in the
> working directory), but I can see how he may have expected behavior
> more along the lines of git rm --cached for those particular files. I
> don't agree with that viewpoint (I see files as tracked as soon as you
> stage it, not once you commit it), but I can see where the expectation
> comes from.
>
> Just my thoughts,
> Elijah
Yes, you have a 100% correct understand of what I'm trying to say.
But can you see a downside to "git reset --hard" treating newly
added files as "git reset"?
Wiping out existing files (with no realistic recovery) is a bit harsh,
isn't it? Especially when AFAICS there's no downside to leaving the
untracked files as they were before they were "git add"-ed.
- Eric
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Nicolas Pitre @ 2008-09-11 20:27 UTC (permalink / raw)
To: Stephen R. van den Berg; +Cc: Linus Torvalds, Jakub Narebski, git
In-Reply-To: <20080911195516.GE1451@cuci.nl>
On Thu, 11 Sep 2008, Stephen R. van den Berg wrote:
> Nicolas Pitre wrote:
> >On Thu, 11 Sep 2008, Stephen R. van den Berg wrote:
> >> when doing things with temporary branches. The origin field is meant to
> >> be filled *ONLY* when cherry-picking from one permanent branch to
> >> another permanent branch. This is a *rare* operation.
>
> >... and therefore you might as well just have a separate file (which
> >might or might not be tracked by git like the .gitignore files are)
> >to keep that information? Since this is a rare operation, modifying the
> >core database structure for this doesn't appear that appealing to most
> >so far.
>
> For various reasons, the best alternate place would be at the trailing
> end of the free-form field. Using a separate structure causes
> (performance) problems (mostly).
Did you try it? I don't particularly buy this performance argument, and
the bulk of my contributions to git so far were about performances. It
is quite easy to load a flat file with sorted commit SHA1s, and given
that origin links are the result of a rare operation, then there
shouldn't be too many entries to search through. Hell, doing 213647
lookups (and many other things like inflating zlib deflated data) with
each of them for commit objects in my Linux repository which has 1355167
total entries takes only 6 seconds here, or about a quarter of a
milisecond for each lookup. I doubt doing an extra lookup in a much
smaller table would show on the radar.
Nicolas
^ permalink raw reply
* Re: RFC: perhaps a "new file" should not be deleted by "git reset --hard"
From: Eric Raible @ 2008-09-11 20:26 UTC (permalink / raw)
To: git
In-Reply-To: <20080911061454.GA8167@glandium.org>
Mike Hommey <mh <at> glandium.org> writes:
> Note that reflog only contains references to commit sha1s, so it can't
> track index status.
Yes I realize that.
My point was that the file is entirely gone (except via "git fsck").
I wouldn't expect the reflog to reference it, but I was just mentioning
it for completeness (since it's often help in recovering from types of
lossage).
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Stephen R. van den Berg @ 2008-09-11 20:24 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Theodore Tso, Jakub Narebski, Linus Torvalds, git
In-Reply-To: <alpine.LFD.1.10.0809111601280.23787@xanadu.home>
Nicolas Pitre wrote:
>On Thu, 11 Sep 2008, Stephen R. van den Berg wrote:
>> Well, the principle of least surprise dictates that they should be kept
>> by gc as described above, however...
>> I can envision an option to gc say "--drop-weak-links" which does
>> exactly what you describe.
>Don't you think this starts to look silly at that point?
No, it's the developers vote controlling his own repository saying:
Ok, I expressed interest in the other branches and their
backport/forwardport relationships, but I changed my mind. Drop all
backport/forwardport information on branches I don't explicitly have.
--
Sincerely,
Stephen R. van den Berg.
"There are three types of people in the world;
those who can count, and those who can't."
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Stephen R. van den Berg @ 2008-09-11 20:22 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Nicolas Pitre, Theodore Tso, Linus Torvalds, git
In-Reply-To: <200809112205.16928.jnareb@gmail.com>
Jakub Narebski wrote:
>Stephen R. van den Berg wrote:
>> Well, the principle of least surprise dictates that they should be kept
>> by gc as described above, however...
>> I can envision an option to gc say "--drop-weak-links" which does
>> exactly what you describe.
>Well, IIRC the need for this was one of the causes of "death" of 'prior'
>header link proposal...
As I understood it, one of the causes of death of the "prior" link
proposal was that it was unclear if it pulled in the linked-to commits
upon fetch. In the "origin" case, the default is *not* to fetch them.
--
Sincerely,
Stephen R. van den Berg.
"There are three types of people in the world;
those who can count, and those who can't."
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Stephen R. van den Berg @ 2008-09-11 20:16 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Paolo Bonzini, Jakub Narebski, git
In-Reply-To: <alpine.LFD.1.10.0809110910430.3384@nehalem.linux-foundation.org>
Linus Torvalds wrote:
>But my point is, _none_ of what Stephen proposes has _any_ advantage over
>the already existing functionality.
I think you're missing some of the advantages because you don't have a
lot of experience with cherry-pick workflows between multiple permanent
branches.
>IOW, absolutely *everything* is actually done better with existing data
>structures, and then just adding tools to perhaps follow those SHA1's in
>the commit message.
The best way to explain the difference is probably by implementing the
free-form support, so I think I'll do that.
>For example, the claim was that it's hard to follow the chain of
>cherry-picks. That's not _true_. Use gitweb and gitk, and you can already
>see them. Sure, you need to use "-x", BUT YOU'D HAVE TO USE THAT WITH
>Steven's MODEL TOO!
The existing cherry-pick -x option doesn't cut it, it helps for the
simple cases, yes, but there are cherry-pick situations where it just
adds to the confusion.
>Exactly because it would be a frigging _disaster_ if that "origin" field
>was done by default.
That never was the intention, and never will be happening.
>And the only thing that "origin" does is:
> - hide the information
Only if you want to hide it, you control if it does, this point is moot.
> - make it easier to make mistakes (either enable the feature by default,
> or not notice that you didn't enable it when you wanted to)
The same holds for -x, so this point is moot as well.
> - add a requirement for a backwards-incompatible field that is just
> guaranteed to confuse any old git binaries.
This is a problem, I admit, but maybe this can be solved in the future.
Then again, since use of the feature is a *very* conscious decision, anyone
using the feature can advise their users to use git version xxx at least.
> - make it _harder_ to do things like send revert/cherry-pick information
> by email.
Not necessarily, adding an Origin field in the patch sent by mail is
easy. I don't see how it would be more difficult otherwise. Please
explain.
>See? There are only downsides.
I think I just neutralised all but one of the mentioned downsides, and
the backward compatibility issue is at least mitigated.
>and then go to its parent commit (just click on the parent SHA). And
>notice how the stable kernel tree commits talk about where they were
>back-ported from, or _why_ they aren't back-ports at all!
And this is impossible when using the origin link? The usage with an
origin link would be just as flexible, even more so.
>IOW, there are really two main cases:
> - the common case for cherry-picking: you do not want any origin
> information, because it's irrelevant, pointless, and *wrong*.
Quite, and my proposal is not generating those anyway.
> - you _do_ want origin information, but you actually want to _explain_
> explicitly why it's not irrelevant, pointless, or wrong.
>And yes, the latter case is about a lot more than "this was
>cherry-picked". It's about "this fixes that other commit we did", or it's
>about "this was anti-cherry-picked - ie reverted". They are all "origins"
>for the commit in the sense that they are relevant to the commit, but they
>all need some explanation of what _kind_ of origins they are.
Yes, and that *extra* information can and should go into the free-form
commit message, alongside of the origin field inside the header (or
trailer), just edit the commit message before committing after a
cherry-pick -o. What's your point?
--
Sincerely,
Stephen R. van den Berg.
"There are three types of people in the world;
those who can count, and those who can't."
^ permalink raw reply
* Git User's Survey 2008 partial summary, part 5 - other SCM
From: Jakub Narebski @ 2008-09-11 20:14 UTC (permalink / raw)
To: git
In-Reply-To: <200809031607.19722.jnareb@gmail.com>
This is partial summary of Git User's Survey 2008 for the state from
Sep 09, 2008, with almost 2300 responses (yes, _thousands_ responses).
It is based on "Analysis" page for this survey:
http://www.survs.com/shareResults?survey=M3PIVU72&rndm=OKJQ45LAG8
We have around 2295 individual responses (excluding 21 responses in the
'testing' channel), for the time I got those data, as compared to
683 individual responses for 2007 survey, and (I think)
115 answers (Base = 115) for 2006 survey. That is a lot,...
I wonder how many replies we would have at the end of survey, Oct 10?
---
Below I concentrated on questions related to other SCM, although not all
those questions were from "Other SCM" section.
12) What other SCM did or do you use?
(Matrix - One answer per row)
The table below is sorted alphabetically, with exception of 'custom'
and 'other' which are put at the end.
==============================================================
SCM | Never | Used it | Still use
--------------------------------------------------------------
AccuRev | 60% (1227) | 0% (6) | 0% (1)
Arch (or clone) | 54% (1108) | 7% (136) | 0% (1) 11
Bazaar-NG | 47% (969) | 12% (257) | 4% (76) 7
BitKeeper | 55% (1135) | 5% (111) | 0% (3) 12
ClearCase | 53% (1101) | 7% (151) | 2% (37) 10
CVS | 12% (242) | 62% (1277) | 13% (260) 1
Darcs | 48% (990) | 13% (262) | 2% (48) 6
Mercurial | 40% (819) | 18% (379) | 8% (174) 5
Monotone | 55% (1136) | 5% (95) | 1% (16) 14
MS SourceSafe | 46% (949) | 19% (401) | 1% (20) 3
MS Studio Team System | 57% (1173) | 3% (56) | 0% (9)
Perforce | 51% (1045) | 9% (191) | 3% (64) 9
PVCS | 56% (1157) | 5% (100) | 0% (3) 13'
RCS | 43% (881) | 19% (389) | 3% (59) 4
SCCS | 56% (1146) | 5% (100) | 0% (7) 13'
Subversion | 3% (59) | 35% (726) | 59% (1217) 2
SVK | 51% (1043) | 11% (226) | 1% (15) 8
..............................................................
custom (non-published) | 54% (1115) | 4% (90) | 1% (22)
other | 51% (1042) | 5% (98) | 1% (22)
--------------------------------------------------------------
Total respondents | 2060
skipped this question | 235
Side note: each of version control systems have at least one
respondent which still use it. That was not assured.
Top 5 "still use", which should mean version control system which
are used beside, and together with Git.
=====================================
SCM | still use
-------------------------------------
1. Subversion | 59% (1217)
2. CVS | 13% (260)
3. Mercurial | 8% (174)
4. Bazaar-NG | 4% (76)
5. Perforce | 3% (64)
.....................................
7. Darcs | 2% (48)
10. Monotone | 1% (16)
Note that 10th place for Monotone excludes 'custom' and 'other';
otherwise it would be 12th.
Analysis: Subversion (SVN) is most popular, eclipsing all other SCMs.
This might be caused by the fact that git-svn is very good in
integrating Subversion with Git enhances and emphasizes popularity of
Subversion. CVS, at time very popular, leaves the field to Subversion
(advertised as replacement fo CVS, as "CVS done right") and other
systems. This agrees with the number of people which have above
version control systems in Ohloh software stack [need new analysis for
final version; for now you can use data from GitSurvey2007 page at git
wiki], and with Debian Popularity Contest (popcon) [here also new data
is needed].
A bit suprising for me is high place of Perforce. Another strange
thing (and a bit alarming) is that MS Visual SourceSafe has higher
place than Monotone; but that might be caused by different design and
different target groups of Monotone and Git, which might have caused
that the communities have almost no overlap; people choose either Git
or Monotone, one or the other. BitKeeper has also a very low number
of active users among Git users... but that is not that strange,
considering history.
See also "Adoption of various VCSes" blog post by Newren:
http://blogs.gnome.org/newren/2007/11/17/adoption-of-various-vcses/
which is less than year old. This essay includes proprietary SCMs
like Perforce.
Top 5 "used it" (assumption: no longer in use) version control
systems. Replaced by Git or other SCM, tried and abandoned, etc.
=====================================
SCM | used it
-------------------------------------
1. CVS | 62% (1277)
2. Subversion | 35% (726)
3. MS SourceSafe | 19% (401)
4. RCS | 19% (389)
5. Mercurial | 18% (379)
.....................................
6. Darcs | 13% (262)
7. Bazaar-NG | 12% (257)
14. Monotone | 5% (95)
Note that again 'other' and 'custom' are excluded.
Analysis: We can see here former glory of CVS, which was once standard
for version control system. Its predecessor, single-file locking
version control system, RCS is also visible.
A bit suprising is 3rd place of MS Visual SourceSafe; I really hope
that it is either "I took a look at it and ran away", or "I had to use
it but fortunately no longer". And what do you think about this?
13) Why did you choose/use Git? (if you use Git)
What do you like about using Git?
(Open ended text - Essay)
Total respondents 1723
skipped this question 572
14) Why did you choose/use other SCMs? (if you use other SCMs)
What do you like about using other SCMs?
(Open ended text - Essay)
Total respondents 1329
skipped this question 966
25) How do you publish/propagate your changes?
(Choice - Multiple answers)
======================================
method | using it
--------------------------------------
push | 91% (1740)
pull request | 29% (551)
format-patch + email | 22% (414)
git bundle | 2% (39)
......................................
git-svn | 26% (498)
other foreign SCM^[*] | 2% (45)
......................................
other | 2% (32)
======================================
Total respondents | 1904
skipped this question | 391
Footnote:
=========
[*] publishing to other foreing SCM:
+ Bazaar, using git-bzr
+ CVS, using git-cvsexportcommit
using git-cvs (probably git-cvsserver)
+ ClearCase, using custom scripts
unspecified method
+ Perforce, using git-p4
using git-p4-import
using patch
+ Mercurial, using fast-import (?)
using email + hg mq
+ AccuRev, using git-acu
+ Quilt, using email
+ SourceSafe, using shared workdir
using custom scripts
+ Subversion, using shared workdir (?)
+ SVK, using shared workdir
+ RCS, using custom scripts
+ TeamWare, using git-tw (unpublished yet)
Analysis, as pertinent to "other SCM" question: as you can see git-svn
is very popular, just below pull request (which probably include
GitHub social interface), and slightly higher (!) than format-patch
plus email, i.e. patch-based workflow.
26) If the way you publish your changes is not mentioned above,
how do you publish your changes? Please explain.
(Open ended text - Essay)
Total respondents 95
skipped this question 2200
Here are listed only methods which are truly not mentioned above
(for example publishing to other SCMs usually doesn't count).
I have also tried to remove duplicated entries:
* git-bzr allows for bidirectional syncing with a git
repository. Useful when a project is hosted in Bazaar.
* Standard diff file encompassing all changes for a specific feature.
* On one machine, I use rsync to push my repository upstream by hand
(for HTTP access).
* Personal use only (many responses).
* we also use a script that uses various git=diff concoctions to
generate patch bundles
* format-patch + lighthouse;
We create patches and attach to tickets in Lighthouse
(lighthouseapp.com) for several open-source projects.
* Patches on reviewboard
* format-patch and attach to bugtracking system
* Just so I can be a little more specific about how I publish. I
primarily use stgit and then put the patches in an issue tracker
(like trac).
* I do format-patch. Then I've written a script that posts to
pastebin.com My friend uses another script that downloads from
pastebin.com ;)
NOTE: why don't use gist.github.com, or even just GitHub...
* forum or IRC to the project owners
* format-patch and uploading to a webserver.
* format-patch + save patch on wiki page
* "git diff > my.patch" and upload to the drupal.org issue queue.
* after-push hooks on github to campfire/lighthouse/twitter
* GTP (Git Torrent Protocol -- my own implementation)
* git archive
* gitweb's snapshot/tarball plugin
* Since my hosting provider is temperamental, I have many projects in
a strange hierarchy, and I want to recreate my repository
precisely, I just tar up my master folder and upload that.
* Because of a retarded network setup out of my control, I use a
disgusting script based on git clone --bare, tar, scp, ssh, and
rsyncing.
* Sometimes as simple and stupid as tarball / scp
* Transport of entire repositories via CD/DVD.
NOTE: wouldn't it be easier to use USB stick and bundles?
* copy the whole changed file or tell them what to change since some
windows people do not know what a patch is or how to apply it :-/
* I use git for a repo with lots of huge files (RAW image files). git
pull/push insists on packing up objects but I'd rather have one
object per file in .git/objects, so I rsync those and then pull the
changeset history via std means.
* For all my projects, I set up a post-update hook on my dreamhost
account to force update. I use a standard remote named "stage".
* Package a RubyGem and upload it to the files area of the relevant
RubyForge project, and make sure the same RubyGem is in my Git repo
so GitHub will generate a gem as well.
* Custom scripts for pull requests and patchbombing
An interesting comment:
* At work I use git for tracking one project I work on. It is a
project with Unix line endings in some files, and Windows file
endings in the other. My company uses VSS which cannot handle Unix
line endings and otherwise is not very powerful. So I use git to
track my history, but use VSS as backup repository. Also I git pull
my git repository to a backup repository on a network drive.
An explanation of choices:
* There are cases where I will push to continuous integration
repositories to get a specific tree tested. Otherwise it is all
about pulling.
* I do not publish my changes. Other people can access a copy of my
code, but I do not use a git repository on a server. I do not
understand that concept good enough (hint: that needs docs for
total dummies)
* I only use git for cloning/pulling repo's for now, since it is too
hard to use. I don't have a lot of spare time to learn it since svn
is easy and useful. I would use it if there was a doc that explains
it to us svn people.
And there is also:
* For 27 and 28, there is no "I don't know< I'm using the GUI's",
so I'm not ticking the answers
* I don't know!
* GitHub; Gitosis; Capistrano
* Send them to somebody who has git access.
NOTE: probably format-patch + email
* can some one provide free private git service?
ANSWER: There are many free _public_ git service, and a few
non-free git services offer private repositories (e.g. GitHub)
* Carrier pigeon
Analysis: as you can see format-patch + <something>, where <something>
is not email or mailing list, but issue tracker, wiki, patch queue or
other web site/web application is quite popular.
Some people use different combinations of tar/zip and scp or other
transport, or rsync, or ssh to simply transfer the whole repository
(some of which might be migitated by using bundles instead, but only
if there is access to shell account on remote site and there is git on
remote site to "unpack" bundle). Sometimes it is caused by the lack
of decent features in a web server, sometimes it is lack of knowledge.
15) Do you miss features in git that you know from other SCMs?
If yes, what features are these (and from which SCM)?
(Open ended text - Essay)
Total respondents 1046 (some/many of them wrote 'no')
skipped this question 1249
This is just a very quick summary, based on a first few pages of
responses, Full analysis is I think best left for after closing the
survey, because I think this would be a lot of work...
So here is preliminary list, or rather beginning of one:
* sparse/partial checkout and clone (e.g. Perforce)
* better MS Windows support (CVS, Mercurial, Darcs, Bazaar)
* integration with IDE/RAD/editor/filemanager
* good GUI/visual tools/graphical shell (on multiple platforms)
* 'soft' locking aka. watching files (like in ClearCase)
* equivalent of 'hg serve': fast web interface and pull-server
in one (Mercurial)
* better documentation (svnbook, hgbook, generic)
* traversing history of individual file (unknown SCM)
* better interface for staging individual changes
(Darcs interface is better than 'git add -i')
* better UI for submodules (less commands to issue, like in Subversion)
* integrated conflict resolution tool
* tracking empty repositories (Bazaar)
+ It would be helpful to have something like "comments" in monotone.
+ hackability and portability of Mercurial
+ good Unicode support, the current implicit handling sucks
+ Hg had less commands to do the same :) (Mercurial)
+ big file support (ClearCase)
+ maybe a 'info' style command where it lists all branches, tags,
remotes and repo specific config. Rather than using separate
commands.
+ I don't miss any *feature* from SVN, but I do miss some of the
terse commands. Reverting my local changes to a file in Git always
feels like hard work, and in SVN it's a dead simple command, etc.
+ svn:externals from subversion (especially the part where one can do
partial imports from other repositories) something in the likes of
hgforest, i.e. having 'live' submodules which are not fixed to a
specific revision (from Mercurial)
* better support for tracking third party tools like 'piston'
for Subversion.
NOTE: there is 'braid', formerly 'giston' for git
* mainly fine-grained commit support (staging diff hunks),
branch management, stashing
NOTE: all of this is available in modern Git
* easier to use commit identifiers. "It's hard to memorize the
seemingly random commit hash (even the short 7-character ones)."
Note that people used this question to put feature requests, instead
_only_ things from other SCMs that they are missing in Git; and even
when they did correctly, they forgot often to state _which_ SCM is
given feature from.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Jakub Narebski @ 2008-09-11 20:05 UTC (permalink / raw)
To: Stephen R. van den Berg; +Cc: Nicolas Pitre, Theodore Tso, Linus Torvalds, git
In-Reply-To: <20080911194447.GD1451@cuci.nl>
Stephen R. van den Berg wrote:
> Nicolas Pitre wrote:
>>On Thu, 11 Sep 2008, Stephen R. van den Berg wrote:
>>> Not quite. Obviously all parents of p and p^ will continue to exist.
>>> I.e. deleting branch B will cause all commits from p till the tip of B
>>> (except p itself) to vanish. Keeping p implies that the whole chain of
>>> parents below p will continue to exist and be reachable. That's the way
>>> a git repository works.
>
>>And that's what I called stupid in my earlier reply to you. Either you
>>have proper branches or tags keeping P around, or deleting B brings
>>everything not reachable through other branches or tags (or reflog)
>>away too. Otherwise there is no point making a dangling origin link
>>valid.
>
> Well, the principle of least surprise dictates that they should be kept
> by gc as described above, however...
> I can envision an option to gc say "--drop-weak-links" which does
> exactly what you describe.
Well, IIRC the need for this was one of the causes of "death" of 'prior'
header link proposal...
--
Jakub Narebski
Poland
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox