* Re: git gc and kernel.org
From: Johannes Sixt @ 2009-10-21 8:05 UTC (permalink / raw)
To: Junio C Hamano
Cc: Nicolas Pitre, Johan Herland, git, H. Peter Anvin, ftpadmin
In-Reply-To: <7vaazl8acd.fsf@alter.siamese.dyndns.org>
Junio C Hamano schrieb:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Johannes Sixt <j.sixt@viscovery.net> writes:
>>
>>> Junio C Hamano schrieb:
>>>> + if (auto_gc) {
>>>> + const char *argv_gc_auto[] = { "gc", "--auto", NULL };
>>>> + run_command_v_opt(argv_gc_auto, RUN_GIT_CMD);
>>> Am I correct that this will produce progress output? If git-daemon runs
>>> receive-pack, then this output will go to the syslog. Do we care?
>> We do, and we don't want that. Thanks for spotting.
>>
>> Would adding "--quiet" to the mix be enough?
>
> Actually I don't know. This originally came from "we _could_ add gc and
> update-server-info to hundreds of post-receive hooks, but any repository
> hosting site that holds many central repositories will exactly have the
> same issue, so why not do this internally", so it may make sense to do
> exactly the same thing as what we do to the output from hooks. What do we
> do to them now? stdout-to-stderr?
Yes.
I'm slightly in favor of adding "--quiet", because even with this option
we see some output:
$ git gc --auto --quiet
Auto packing your repository for optimum performance. You may also
run "git gc" manually. See "git help gc" for more information.
A compromise would be to reduce this message to the first sentence if
--quiet was given. This way users who push via ssh or locally get a short
explanation why "git push" does not finish immediately[*]; and git-daemon
logs only a one-liner in the syslog, which might be useful, too.
[*] Skipping the hint to "run git gc manually" would even be good in this
case, because the hint pertains the remote repository, not the one from
which "git push" was issued.
-- Hannes
^ permalink raw reply
* Re: [PATCH] pull: refuse complete src:dst fetchspec arguments
From: Thomas Rast @ 2009-10-21 8:05 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Daniel Barkalow, Sean Estabrooks, git
In-Reply-To: <20091021031528.GB18997@atjola.homenet>
Björn Steinbrink wrote:
> One (maybe important) difference there is that the "pull" gets you:
>
> Merge branch 'pu' of git://git.kernel.org/pub/scm/git/git
>
> Even with "master:tmp". But with fetch+merge (storing in refs/remotes):
>
> Merge remote branch 'tmp'
What if any combination of fetch and merge always gave you the long
form? After all, even if you do have a tracking branch for whatever
you are merging, that information is probably useless and it would be
nicer if all of the following resulted in the long form:
* git fetch git://git.kernel.org/pub/scm/git/git pu
git merge FETCH_HEAD
* git remote add origin git://git.kernel.org/pub/scm/git/git
git fetch origin
git merge origin/pu
* git fetch git://git.kernel.org/pub/scm/git/git pu:tmp
git merge tmp
and so on.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH] pull: refuse complete src:dst fetchspec arguments
From: Thomas Rast @ 2009-10-21 8:06 UTC (permalink / raw)
To: Sean Estabrooks; +Cc: git
In-Reply-To: <BLU0-SMTP97AA2287062D9A104101C8AEC00@phx.gbl>
Sean Estabrooks wrote:
> Instead of removing this test it should be modified or replaced
> with a test that ensures the new functionality operates correctly.
> In this case that would mean checking that using a full refspec
> errors out.
Indeed, sorry. I meant it to be flagged as an RFC patch, and with
those I usually go for the minimal possible effort to not break the
test suite outright. As such, it also lacks doc updates.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* [PATCH] Quote ' as \(aq in manpages
From: Thomas Rast @ 2009-10-21 8:24 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <200910151402.56295.trast@student.ethz.ch>
The docbook/xmlto toolchain insists on quoting ' as \'. This does
achieve the quoting goal, but modern 'man' implementations turn the
apostrophe into a unicode "proper" apostrophe (given the right
circumstances), breaking code examples in many of our manpages.
Quote them as \(aq instead, which is an "apostrophe quote" as per the
groff_char manpage.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
I've had this around since my last rant, and it actually gives good
results with both setups I can test on, which are:
- asciidoc 8.4.5, docbook-xsl 1.75.2, xmlto 0.0.18
- asciidoc 8.2.7, docbook-xsl 1.73.2, xmlto 0.0.20
Documentation/manpage-base.xsl | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/Documentation/manpage-base.xsl b/Documentation/manpage-base.xsl
index a264fa6..bf74bb7 100644
--- a/Documentation/manpage-base.xsl
+++ b/Documentation/manpage-base.xsl
@@ -7,6 +7,15 @@
<xsl:param name="man.output.quietly" select="1"/>
<xsl:param name="refentry.meta.get.quietly" select="1"/>
+<xsl:template name="escape.apostrophe">
+ <xsl:param name="content"/>
+ <xsl:call-template name="string.subst">
+ <xsl:with-param name="string" select="$content"/>
+ <xsl:with-param name="target">'</xsl:with-param>
+ <xsl:with-param name="replacement">\(aq</xsl:with-param>
+ </xsl:call-template>
+</xsl:template>
+
<!-- convert asciidoc callouts to man page format;
git.docbook.backslash and git.docbook.dot params
must be supplied by another XSL file or other means -->
--
1.6.5.1.144.g40216
^ permalink raw reply related
* Re: [PATCH 7/6 (v4)] support for commit grafts, slight change to general mechanism
From: Thomas Rast @ 2009-10-21 9:15 UTC (permalink / raw)
To: Nick Edelen
Cc: Junio C Hamano, Nicolas Pitre, Johannes Schindelin, Sam Vilain,
Michael J Gruber, Jeff King, Shawn O. Pearce, Andreas Ericsson,
Christian Couder, git@vger.kernel.org
In-Reply-To: <4ADCCCA9.4000802@gmail.com>
Nick Edelen wrote:
> Adds support for graft commits in rev-cache (w/ test), and slightly alters
> graft mechanism. Before, parse_commit() checked the graft list on every
> commit. Now register_commit_graft() preemptively loads graft commits into
> memory, and sets a new 'graft' flag in the object. This allows awareness of
> the commits' medical history without searching a (normally private) array upon
> each commit.
I felt adventurous and merged the topic into my local build, but I get
"error: duplicate graft data ..." in repositories with only a single
line in .git/info/grafts, which bisects to this commit (1c0a666 in
today's pu).
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: git gc and kernel.org
From: Jan Krüger @ 2009-10-21 10:21 UTC (permalink / raw)
To: Johannes Sixt
Cc: Junio C Hamano, Nicolas Pitre, Johan Herland, git, H. Peter Anvin,
ftpadmin
In-Reply-To: <4ADEC0DB.4000104@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> wrote:
> $ git gc --auto --quiet
> Auto packing your repository for optimum performance. You may also
> run "git gc" manually. See "git help gc" for more information.
> [...]
> [*] Skipping the hint to "run git gc manually" would even be good in
> this case, because the hint pertains the remote repository, not the
> one from which "git push" was issued.
I agree with your suggestions. On the same note, while we're already
changing the message, it might make sense to change it to "Auto packing
the repository [...]".
Jan
^ permalink raw reply
* Re: [PATCH] Quote ' as \(aq in manpages
From: Miklos Vajna @ 2009-10-21 10:38 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Junio C Hamano
In-Reply-To: <ab31eb03b25272341b91e1f1132dab9d8a49e5b6.1256113282.git.trast@student.ethz.ch>
[-- Attachment #1: Type: text/plain, Size: 872 bytes --]
On Wed, Oct 21, 2009 at 10:24:42AM +0200, Thomas Rast <trast@student.ethz.ch> wrote:
> The docbook/xmlto toolchain insists on quoting ' as \'. This does
> achieve the quoting goal, but modern 'man' implementations turn the
> apostrophe into a unicode "proper" apostrophe (given the right
> circumstances), breaking code examples in many of our manpages.
>
> Quote them as \(aq instead, which is an "apostrophe quote" as per the
> groff_char manpage.
>
> Signed-off-by: Thomas Rast <trast@student.ethz.ch>
> ---
>
> I've had this around since my last rant, and it actually gives good
> results with both setups I can test on, which are:
>
> - asciidoc 8.4.5, docbook-xsl 1.75.2, xmlto 0.0.18
> - asciidoc 8.2.7, docbook-xsl 1.73.2, xmlto 0.0.20
Tested-by: Miklos Vajna <vmiklos@frugalware.org>
- asciidoc 8.3.5, docbook-xsl 1.74.0, xmlto 0.0.20
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Finding a commit
From: Soham Mehta @ 2009-10-21 11:29 UTC (permalink / raw)
To: git
Given a SHA1 of a commit from one repository (say x), wondering what is
a proper way to find out if that commit (change) also exists in a
different repository (say y).
Because SHA1 can change if a commit is cherry-picked around, I cannot
just grep for that SHA1 from git-rev-list or git-log on 'y'. I need a
way to know if a commit with identical changes (as in 'x') is also
present in 'y'.
I realize that Author and Timestamp do not change when the commit is
moved (fetched, pushed, pulled, rebased, cherry-picked etc). So my
current solution relies on grepping for the pair of Author-Timestamp
from git-log on 'y'.
Wondering if there is more appropriate way of doing this?
Thanks.
-Soham
^ permalink raw reply
* Re: [RFC] pull/fetch rename
From: Björn Steinbrink @ 2009-10-21 11:57 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Thomas Rast, git
In-Reply-To: <alpine.LNX.2.00.0910202310070.14365@iabervon.org>
On 2009.10.21 00:22:18 -0400, Daniel Barkalow wrote:
> On Wed, 21 Oct 2009, Björn Steinbrink wrote:
>
> > 3) User expects "pull" to update all branch heads that have a configured
> > upstream
> >
> > 08:31 dimsuz hi guys! suppose i'm currently on master. then run git
> > fetch. which delivers updates to master and other
> > branches. I don't merge anything, but do checkout some
> > branch (which is not master). Question: will these new
> > updates get into this branch automatically after i check
> > it out? question2: will branch master contain those
> > updates when i ckeck it out later?
> > 08:32 Circuitsoft dimsuz. After a fetch, no.
> > 08:33 Circuitsoft However, if you pull, any branches that were set
> > up as local tracking branches will get updated.
> > 08:33 Circuitsoft Otherwise, only remote tracking branches will be
> > updated.
> >
> > http://colabti.de/irclogger/irclogger_log/git?date=2009-10-20#l969
> > (No idea about that one, have seen that once before, but it's definitely
> > not even remotely as common as the others)
>
> I'd guess that's due to having local branches with no local changes, just
> to avoid detached HEAD, and therefore thinking it's normal to have a bunch
> of local branches that could be updated without merges. But I'm on a crazy
> "everybody really wants detached HEAD and is needlessly scared" kick, and
> I'm probably reading too much into it.
Just to clarify: I didn't mean the question (which I didn't really
understand) in this case, but the answer from Circuitsoft (second to
last line). But maybe you also meant that? The question confuses me
enough not to be able to follow.
> > 4) User expects "pull" to create branches
> >
> > 07:25 fynn Hey, I just pulled a branch from remote, and I don't see
> > it in "git branch"
> > 07:25 doener fynn: if you "pull" that means "fetch this and merge it
> > to what I have checked out"
> > 07:25 fynn doener: hm, I just did "git pull" and it showed the new
> > branch
> > 07:26 fynn but I don't see it in my branches...
> > 07:26 fynn doener: should I create that branch as a tracking branch
> > first?
> > 07:26 doener fynn: you're looking at "git branch -r" or "git branch
> > -a", right?
> > 07:26 fynn doener: yeah, I'm seeing it in origin/foo, but not
> > local.
> > 07:26 doener fynn: the "git fetch" should have created a remote
> > tracking branch, as usual, not a local branch head
> > (which would be shown by just "git branch")
> > 07:27 fynn doener: OK, what should I do to create it locally then?
> > 07:28 doener fynn: just the usual "git branch foo origin/foo", or to
> > checkout at the same time: "git checkout -b foo
> > origin/foo" or "git checkout -t origin/foo" (shortcut)
> >
> > http://colabti.de/irclogger/irclogger_log/git?date=2009-10-19#l830
> > (Note how my "fetch this and merge it" is actually inaccurate for just
> > "git pull", there is no "this" and that case. I took "pulled a branch"
> > to mean that he did "git pull <remote> <branch>", which wouldn't have
> > created/update the remote tracking branch [or did patches for that go
> > in? I lost track...])
>
> That sounds like a real converse of "push", including creating like-named
> local branches. Or, perhaps, this is someone expecting that "pull" is like
> "clone" in creating an initial local branch with the name and value of a
> specified remote branch.
Reading that one again, I realize that I've still been confused by the
"pulled a branch". What happened was that the user did "git pull", which
ran "git fetch <remote>", which fetched a new branch head and has shown
that. At that point, the user (and me) got confused for maybe two reasons:
a) He didn't clearly distinguish between the fetch and the merge part.
The new branch wasn't pulled, but just fetched. That caused the user to
think that he "pulled the branch" (wrong terminology), which in term
confused me (wrong use-case assumed).
b) He expected local branch heads to be created, instead of remote
tracking branches. If my memory doesn't play tricks on me, that's
actually not to be expected from that specific user (I think we told him
about remote tracking branches before, and the last part of the
conversation actually suggests that, too). If I don't forget, I'll try
to get feedback from him the next time he's around.
> > 5) User possibly expecting "pull" to be able to act as "reset --hard"
> >
> > 21:01 aidan What do I do about this: html/config/core.php: needs
> > update
> > 21:02 aidan git pull (gives that)
> > 21:02 Ilari aidan: You have uncommitted changes to that file...
> > 21:15 aidan Ilari: how can I just pull master and overwrite any
> > changes?
> >
> > http://colabti.de/irclogger/irclogger_log/git?date=2009-10-18#l2130
> > (I'm not sure about that one, "overwrite any changes" might mean "drop
> > uncommitted changes and merge" or "just get me the remote's state,
> > dropping my commits and uncommitted changes". Most of the time I've seen
> > similar requests, the user wanted the latter).
>
> So I think that's a desire for "git checkout ." first of all (with the
> assumption that the content without modifications has to come from
> somewhere remote). I don't know what's up with people not wanting to save
> their commits, though.
You haven't seen the multitude of "I have merge conflicts and just want
to take theirs/mine" requests. That often gets more weird than just
"drop my commits" ;-)
> > 6) User says "pull" but probably means "fetch"
> >
> > 14:08 Alien_Freak once I have a clone of a repo I know you can do
> > a checkout tag but is there anyway to pull just
> > the tag?
> >
> > http://colabti.de/irclogger/irclogger_log/git?date=2009-10-16#l1664
> > (There was no answer, thus it's hard to tell, but I guess he wanted
> > something like:
> > git init; git fetch --no-tags url tag <tag>; git checkout <tag>
> > At least I'm quite sure he didn't mean "pull" as in "git pull")
>
> I don't know; you can actually do:
>
> $ git init; git pull --no-tags <url> tag <tag>
>
> It updates the master branch and working directory from (nothing) to the
> fetched tag.
Hm, yeah, that works (didn't think of it), but it's a rather special
case. Teaching that might lead to misunderstandings about what "pull"
does, I think. It would look somewhat like "fetch + reset --hard".
> > 8) "reset --hard" again
> >
> > 20:10 roger_padactor i commited then did a pull how do i get back to
> > my commit. the pull over wrote the files
> > 20:11 merlin83 roger_padactor: you can't, pull == fetch + hard
> > reset to latest commit
> >
> > http://colabti.de/irclogger/irclogger_log/git?date=2009-10-14#l2306
> > (Someone being told that pull is fetch + reset --hard is actually new to
> > me. Only saw that as an expectation previously.)
>
> That's odd. How could you not notice that it doesn't actually do that,
> even if you try to get it to?
Hm? roger_padactor noticed that "pull" changed his files and wants to go
back. And merlin83 says that that is impossible because pull supposedly
does reset --hard. There's nothing in there (I could see) that suggests
that anyone tried to make "pull" do "reset --hard".
merlin83 basically made three mistakes, I think:
1) Assume that roger_padactor was talking about uncommitted changes
2) Assume that pull is fetch + reset --hard
3) Assume that you can't undo a reset --hard for committed changes
(OK, 3) isn't actually valid when you consider 1), but 1) is so invalid
that I kept 3). After all, "pull" would complain about a dirty tree...)
> Actually, I wonder if the right formula is update = fetch + checkout.
> There are a lot of people (IMHO) want "git fetch origin; git checkout
> origin/master", and I think their first idea is "git update", but that
> doesn't exist, and they find "pull" as the closest thing.
That has a precondition that the user is already using a detached HEAD.
Otherwise that fetch + checkout would likely mean that the get baffled
when they do:
git checkout master
git update
git checkout foo
git checkout master
Seeing that "master" is out of date "again".
I agree though, that users might look for "git update" and because it is
missing, they just look for the closest thing. Adding Junio's statement
that users seem to want recipes instead of flexibility (and seeing
"update" as just "get me new stuff from upstream" without meaning any
specific method of updating), I think that "git update" could be a "recipe
collection" tool. I'll hack that into my proof-of-concept thing (which
I hope to have ready for a RFC next week).
Björn
^ permalink raw reply
* [PATCH 1/2] Remove a left-over file from t/t5100
From: Johannes Sixt @ 2009-10-21 11:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Sixt
This mbox file must have been added by accident in e9fe804 (git-mailinfo:
Fix getting the subject from the in-body [PATCH] line, 2008-07-14).
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
I noticed this while I was looking at the effects of the next patch.
t/t5100/0010 | 35 -----------------------------------
1 files changed, 0 insertions(+), 35 deletions(-)
delete mode 100644 t/t5100/0010
diff --git a/t/t5100/0010 b/t/t5100/0010
deleted file mode 100644
index f5892c9..0000000
--- a/t/t5100/0010
+++ /dev/null
@@ -1,35 +0,0 @@
-From b9704a518e21158433baa2cc2d591fea687967f6 Mon Sep 17 00:00:00 2001
-From: =?UTF-8?q?Lukas=20Sandstr=C3=B6m?= <lukass@etek.chalmers.se>
-Date: Thu, 10 Jul 2008 23:41:33 +0200
-Subject: Re: discussion that lead to this patch
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-[PATCH] git-mailinfo: Fix getting the subject from the body
-
-"Subject: " isn't in the static array "header", and thus
-memcmp("Subject: ", header[i], 7) will never match.
-
-Signed-off-by: Lukas Sandström <lukass@etek.chalmers.se>
-Signed-off-by: Junio C Hamano <gitster@pobox.com>
----
- builtin-mailinfo.c | 2 +-
- 1 files changed, 1 insertions(+), 1 deletions(-)
-
-diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c
-index 962aa34..2d1520f 100644
---- a/builtin-mailinfo.c
-+++ b/builtin-mailinfo.c
-@@ -334,7 +334,7 @@ static int check_header(char *line, unsigned linesize, char **hdr_data, int over
- return 1;
- if (!memcmp("[PATCH]", line, 7) && isspace(line[7])) {
- for (i = 0; header[i]; i++) {
-- if (!memcmp("Subject: ", header[i], 9)) {
-+ if (!memcmp("Subject", header[i], 7)) {
- if (! handle_header(line, hdr_data[i], 0)) {
- return 1;
- }
---
-1.5.6.2.455.g1efb2
-
--
1.6.5.1028.g985e.dirty
^ permalink raw reply related
* [PATCH 2/2] Mark files in t/t5100 as UTF-8
From: Johannes Sixt @ 2009-10-21 11:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Sixt
In-Reply-To: <1256124916-26486-1-git-send-email-j6t@kdbg.org>
This enables gitk to show the patch text with correct glyphs if the locale
is not UTF-8.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
This is particularly interesting for users on Windows, because we
do not have a usable UTF-8 locale.
t/t5100/.gitattributes | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
create mode 100644 t/t5100/.gitattributes
diff --git a/t/t5100/.gitattributes b/t/t5100/.gitattributes
new file mode 100644
index 0000000..feeebf2
--- /dev/null
+++ b/t/t5100/.gitattributes
@@ -0,0 +1,4 @@
+msg* encoding=UTF-8
+info* encoding=UTF-8
+rfc2047-info-* encoding=UTF-8
+sample.mbox encoding=UTF-8
--
1.6.5.1028.g985e.dirty
^ permalink raw reply related
* Re: [msysGit] [PATCH v4 7/8] mingw: enable OpenSSL
From: Johannes Sixt @ 2009-10-21 12:15 UTC (permalink / raw)
Cc: msysgit, git, Erik Faye-Lund, Marius Storm-Olsen
In-Reply-To: <200910192020.44890.j6t@kdbg.org>
Johannes Sixt schrieb:
> On Montag, 19. Oktober 2009, Erik Faye-Lund wrote:
>> Since we have OpenSSL in msysgit now, enable it to support SSL
>> encryption for imap-send.
>>
>> Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
>
> Acked-by: Johannes Sixt <j6t@kdbg.org>
I seem to have ack'ed this one too early. After testing in my environment,
I get:
imap-send.o: In function `ssl_socket_perror':
D:\Src\mingw-git/imap-send.c:241: undefined reference to `ERR_get_error'
D:\Src\mingw-git/imap-send.c:241: undefined reference to `ERR_error_string'
I need this patch in addition, and perhaps something similar is also
needed with MSVC:
diff --git a/Makefile b/Makefile
index c4b91d8..7e6a1c3 100644
--- a/Makefile
+++ b/Makefile
@@ -932,6 +932,7 @@ else
ifneq (,$(findstring MINGW,$(uname_S)))
pathsep = ;
NO_PREAD = YesPlease
+ NEEDS_CRYPTO_WITH_SSL = YesPlease
NO_LIBGEN_H = YesPlease
NO_SYMLINK_HEAD = YesPlease
NO_IPV6 = YesPlease
^ permalink raw reply related
* Re: Finding a commit
From: Daniele Segato @ 2009-10-21 12:30 UTC (permalink / raw)
To: Soham Mehta; +Cc: git
In-Reply-To: <4ADEF095.3020406@box.net>
On Wed, Oct 21, 2009 at 1:29 PM, Soham Mehta <soham@box.net> wrote:
> Because SHA1 can change if a commit is cherry-picked around, I cannot just
> grep for that SHA1 from git-rev-list or git-log on 'y'. I need a way to know
> if a commit with identical changes (as in 'x') is also present in 'y'.
I'm really not an expert of git..
but A commit is something like:
Commit -> Tree ---> Blob1, Blob2, Blob3
Commit, Trees and Blobs are all identified by sha1
the commit should keep information on the author, the "parent"
commit(s) and so on..
the tree should just keep the "snapshot" of the data..
so I think that if you search for the SHA-1 of the tree you should be fine..
But I don't know how you can get the SHA-1 of the tree from a commit
(may be git cat-file <commit-sha> could help you)
and I don't know how to search for that tree around your index...
But I'm sure google (or whatever) has the answer to those questions,
regards,
Daniele
^ permalink raw reply
* Re: Finding a commit
From: Thomas Rast @ 2009-10-21 12:37 UTC (permalink / raw)
To: Daniele Segato, Soham Mehta; +Cc: git
In-Reply-To: <9accb4400910210530k75a763cbtbc9294d937de9242@mail.gmail.com>
Daniele Segato wrote:
> On Wed, Oct 21, 2009 at 1:29 PM, Soham Mehta <soham@box.net> wrote:
> > Because SHA1 can change if a commit is cherry-picked around, I cannot just
> > grep for that SHA1 from git-rev-list or git-log on 'y'. I need a way to know
> > if a commit with identical changes (as in 'x') is also present in 'y'.
man git-patch-id (online at http://git.or.cz/man/git-patch-id).
Note that if the cherry-pick conflicted, you'll get a different
patch-id.
> I'm really not an expert of git..
>
> but A commit is something like:
>
> Commit -> Tree ---> Blob1, Blob2, Blob3
>
> Commit, Trees and Blobs are all identified by sha1
> the commit should keep information on the author, the "parent"
> commit(s) and so on..
> the tree should just keep the "snapshot" of the data..
>
> so I think that if you search for the SHA-1 of the tree you should be fine..
Not if you really want to find out if X was cherry-picked into this
repository, because the tree is the *final state* at that commit,
which of course includes all preceding changes.
So suppose you have two patches A.diff and B.diff introducing files of
the same name; then if you combine them into history as
A -- B
the tree state at B has both files, and hence is different from the
tree state of B' in
B' -- A'
because there it only has the file B.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH v4 7/8] mingw: enable OpenSSL
From: Erik Faye-Lund @ 2009-10-21 12:43 UTC (permalink / raw)
To: Johannes Sixt; +Cc: msysgit, git, Marius Storm-Olsen
In-Reply-To: <4ADEFB6D.9050501@viscovery.net>
On Wed, Oct 21, 2009 at 2:15 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> I seem to have ack'ed this one too early. After testing in my environment,
> I get:
>
> imap-send.o: In function `ssl_socket_perror':
> D:\Src\mingw-git/imap-send.c:241: undefined reference to `ERR_get_error'
> D:\Src\mingw-git/imap-send.c:241: undefined reference to `ERR_error_string'
>
> I need this patch in addition, and perhaps something similar is also
> needed with MSVC:
Ah, yes - thanks for that one. I traced it a bit, and I found that it
works for me without your patch because I'm using OpenSSL's sha1, so
$(LIB_4_CRYPTO) is already included. Your fix is of course correct.
I'll squash it in and resend.
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* Re: [msysGit] [PATCH v4 7/8] mingw: enable OpenSSL
From: Johannes Sixt @ 2009-10-21 12:55 UTC (permalink / raw)
To: kusmabite; +Cc: msysgit, git, Marius Storm-Olsen
In-Reply-To: <40aa078e0910210543t2dcc2af6ie16eb0e49895788f@mail.gmail.com>
Erik Faye-Lund schrieb:
> On Wed, Oct 21, 2009 at 2:15 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
>> I seem to have ack'ed this one too early. After testing in my environment,
>> I get:
>>
>> imap-send.o: In function `ssl_socket_perror':
>> D:\Src\mingw-git/imap-send.c:241: undefined reference to `ERR_get_error'
>> D:\Src\mingw-git/imap-send.c:241: undefined reference to `ERR_error_string'
>>
>> I need this patch in addition, and perhaps something similar is also
>> needed with MSVC:
>
> Ah, yes - thanks for that one. I traced it a bit, and I found that it
> works for me without your patch because I'm using OpenSSL's sha1, so
> $(LIB_4_CRYPTO) is already included. Your fix is of course correct.
> I'll squash it in and resend.
Indeed, I observed the failure after I set BLK_SHA1=YesPlease. I did this
exactly because it removes the dependency on libcrypto.dll from git.exe.
-- Hannes
^ permalink raw reply
* Re: Finding a commit
From: Douglas Campos @ 2009-10-21 13:26 UTC (permalink / raw)
To: Soham Mehta; +Cc: git
In-Reply-To: <4ADEF095.3020406@box.net>
On Wed, Oct 21, 2009 at 9:29 AM, Soham Mehta <soham@box.net> wrote:
> Given a SHA1 of a commit from one repository (say x), wondering what is a
> proper way to find out if that commit (change) also exists in a different
> repository (say y).
>
> Because SHA1 can change if a commit is cherry-picked around, I cannot just
> grep for that SHA1 from git-rev-list or git-log on 'y'. I need a way to know
> if a commit with identical changes (as in 'x') is also present in 'y'.
>
> I realize that Author and Timestamp do not change when the commit is moved
> (fetched, pushed, pulled, rebased, cherry-picked etc). So my current
> solution relies on grepping for the pair of Author-Timestamp from git-log on
> 'y'.
>
Have you tried git cherry?
--
Douglas Campos (qmx)
+55 11 7626 5959
^ permalink raw reply
* [PATCH v3] new --dirty option for git describe
From: Jean Privat @ 2009-10-21 13:35 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Shawn O. Pearce
With the --dirty option, git describe works on HEAD but append "-dirty"
if the working tree is dirty. If the working tree is clean, nothing
is appended.
$ git describe --dirty
v1.6.5-15-gc274db7
$ echo >> Makefile
$ git describe --dirty
v1.6.5-15-gc274db7-dirty
--dirty can also be used to specify what is append if the working
tree is dirty.
$ git describe --dirty=.mod
v1.6.5-15-gc274db7.mod
Many build scripts use `git describe` to produce a version number based
on the description of HEAD (on which is based the working tree) + saying
that if the working tree is dirty or no.
This patch helps the writing of such scripts since `git describe --dirty`
do directly the intended thing.
Alternatives specifications:
1 Describe the working tree by default and describe HEAD only if "HEAD"
is explicitly specified
Pro: does the right thing by default (both for users and for scripts)
Pro: is coherent with other git commands that works on the working tree
by default
Con: breaks existing scripts (since the world is not ideal)
2 Use --worktree instead of --dirty
Pro: does what it says: "git describe --worktree" will describe the
working three
Con: is incoherent with other commands that do not require a --worktree
option to work on the working tree
Con: unusable with an optional value: "git describe --worktree=.mod"
is quite unintuitive.
3 Use --dirty as in this patch
Pro: make sense to specify an optional value (what the dirty mark is)
Pro: do not have any of the big cons of previous alternatives
* does not break scripts
* is not inconsistent with other git commands
Pro: has an easy fallback to alternative 1 if the world become suddenly
ideal, or at least allows some kind of future transition plan if
people *really* bother:
1- ask that scripts use either "git describe HEAD" or
"git describe --dirty" (no more "git describe")
2- change default
Once the transition is done, the role of the --dirty option will
just be the way to specify an alternative mark (and a noop if alone)
Signed-off-by: Jean Privat <jean@pryen.org>
---
Changes since v2.5:
Use test_must_fail
Changes since v2:
No more line breaks (I hope)
Changes since v1:
use --dirty (alternative 3) instead of defaulting on workdir (alternative 1)
---
Documentation/git-describe.txt | 6 ++++++
builtin-describe.c | 25 ++++++++++++++++++++++++-
t/t6120-describe.sh | 14 ++++++++++++++
3 files changed, 44 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt
index b231dbb..5253d86 100644
--- a/Documentation/git-describe.txt
+++ b/Documentation/git-describe.txt
@@ -9,6 +9,7 @@ git-describe - Show the most recent tag that is reachable from a commit
SYNOPSIS
--------
'git describe' [--all] [--tags] [--contains] [--abbrev=<n>] <committish>...
+'git describe' [--all] [--tags] [--contains] [--abbrev=<n>] --dirty[=<mark>]
DESCRIPTION
-----------
@@ -27,6 +28,11 @@ OPTIONS
<committish>...::
Committish object names to describe.
+--dirty[=<mark>]::
+ Describe the working tree.
+ It means describe HEAD and appends <mark> (`-dirty` by
+ default) if the working tree is dirty.
+
--all::
Instead of using only the annotated tags, use any ref
found in `.git/refs/`. This option enables matching
diff --git a/builtin-describe.c b/builtin-describe.c
index df67a73..84af981 100644
--- a/builtin-describe.c
+++ b/builtin-describe.c
@@ -5,12 +5,14 @@
#include "builtin.h"
#include "exec_cmd.h"
#include "parse-options.h"
+#include "diff.h"
#define SEEN (1u<<0)
#define MAX_TAGS (FLAG_BITS - 1)
static const char * const describe_usage[] = {
"git describe [options] <committish>*",
+ "git describe [options] --dirty",
NULL
};
@@ -23,6 +25,13 @@ static int max_candidates = 10;
static int found_names;
static const char *pattern;
static int always;
+static const char *dirty;
+
+/* diff-index command arguments to check if working tree is dirty. */
+static const char *diff_index_args[] = {
+ "diff-index", "--quiet", "HEAD", "--", NULL
+};
+
struct commit_name {
struct tag *tag;
@@ -208,6 +217,8 @@ static void describe(const char *arg, int last_one)
display_name(n);
if (longformat)
show_suffix(0, n->tag ? n->tag->tagged->sha1 : sha1);
+ if (dirty)
+ printf("%s", dirty);
printf("\n");
return;
}
@@ -265,7 +276,10 @@ static void describe(const char *arg, int last_one)
if (!match_cnt) {
const unsigned char *sha1 = cmit->object.sha1;
if (always) {
- printf("%s\n", find_unique_abbrev(sha1, abbrev));
+ printf("%s", find_unique_abbrev(sha1, abbrev));
+ if (dirty)
+ printf("%s", dirty);
+ printf("\n");
return;
}
die("cannot describe '%s'", sha1_to_hex(sha1));
@@ -300,6 +314,8 @@ static void describe(const char *arg, int last_one)
display_name(all_matches[0].name);
if (abbrev)
show_suffix(all_matches[0].depth, cmit->object.sha1);
+ if (dirty)
+ printf("%s", dirty);
printf("\n");
if (!last_one)
@@ -324,6 +340,9 @@ int cmd_describe(int argc, const char **argv, const char *prefix)
"only consider tags matching <pattern>"),
OPT_BOOLEAN(0, "always", &always,
"show abbreviated commit object as fallback"),
+ {OPTION_STRING, 0, "dirty", &dirty, "mark",
+ "append <mark> on dirty working tree (default: \"-dirty\")",
+ PARSE_OPT_OPTARG, NULL, "-dirty"},
OPT_END(),
};
@@ -360,7 +379,11 @@ int cmd_describe(int argc, const char **argv, const char *prefix)
}
if (argc == 0) {
+ if (dirty && !cmd_diff_index(ARRAY_SIZE(diff_index_args) - 1, diff_index_args, prefix))
+ dirty = NULL;
describe("HEAD", 1);
+ } else if (dirty) {
+ die("--dirty is incompatible with committishes");
} else {
while (argc-- > 0) {
describe(*argv++, argc == 0);
diff --git a/t/t6120-describe.sh b/t/t6120-describe.sh
index 8c7e081..e061177 100755
--- a/t/t6120-describe.sh
+++ b/t/t6120-describe.sh
@@ -123,6 +123,20 @@ test_expect_success 'rename tag Q back to A' '
test_expect_success 'pack tag refs' 'git pack-refs'
check_describe A-* HEAD
+check_describe "A-*[0-9a-f]" --dirty
+
+test_expect_success 'set-up dirty working tree' '
+ echo >>file
+'
+
+check_describe "A-*[0-9a-f]-dirty" --dirty
+
+check_describe "A-*[0-9a-f].mod" --dirty=.mod
+
+test_expect_success 'describe --dirty HEAD' '
+ test_must_fail git describe --dirty HEAD
+'
+
test_expect_success 'set-up matching pattern tests' '
git tag -a -m test-annotated test-annotated &&
echo >>file &&
--
1.6.5
^ permalink raw reply related
* Feature request: Store comments on branches
From: Patrick Schoenfeld @ 2009-10-21 13:37 UTC (permalink / raw)
To: git
Hi,
I regulary work with various branches, that I call by the number
of an associated bug tracking / support tracking number. That
makes it clear to which ticket a given branch belongs.
In this case I would find it very useful, if I could associate
short comments with a branch, which would be shown when
doing a 'git branch'. This way I could see what this branch
about, without looking up the ticket information.
Obvious the workaround is to name the branches different,
but this is sometimes not convenient and may result in quiet
long branch names.
What do others think about this? Would this be useful
for others, too?
Best Regards,
Patrick
^ permalink raw reply
* Re: [PATCH 7/6 (v4)] support for commit grafts, slight change to general mechanism
From: Thomas Rast @ 2009-10-21 13:44 UTC (permalink / raw)
To: Nick Edelen
Cc: Junio C Hamano, Nicolas Pitre, Johannes Schindelin, Sam Vilain,
Michael J Gruber, Jeff King, Shawn O. Pearce, Andreas Ericsson,
Christian Couder, git@vger.kernel.org
In-Reply-To: <200910211115.25017.trast@student.ethz.ch>
Thomas Rast wrote:
> Nick Edelen wrote:
> > Adds support for graft commits in rev-cache (w/ test), and slightly alters
> > graft mechanism. Before, parse_commit() checked the graft list on every
> > commit. Now register_commit_graft() preemptively loads graft commits into
> > memory, and sets a new 'graft' flag in the object. This allows awareness of
> > the commits' medical history without searching a (normally private) array upon
> > each commit.
>
> I felt adventurous and merged the topic into my local build, but I get
> "error: duplicate graft data ..." in repositories with only a single
> line in .git/info/grafts, which bisects to this commit (1c0a666 in
> today's pu).
Here's the complaint in squashable form if you want to keep it as a
testcase:
diff --git i/t/t6001-rev-list-graft.sh w/t/t6001-rev-list-graft.sh
index b2131cd..49ba37b 100755
--- i/t/t6001-rev-list-graft.sh
+++ w/t/t6001-rev-list-graft.sh
@@ -110,4 +110,18 @@ do
"
done
+
+duplicate_error="error: duplicate graft"
+
+test_expect_success 'duplicates: no false positives' '
+ echo $B0 $A2 > .git/info/grafts &&
+ ! git rev-list -1 HEAD 2>&1 | grep -q "$duplicate_error"
+'
+
+test_expect_success 'duplicates: no false negatives' '
+ echo $B0 $A2 > .git/info/grafts &&
+ echo $B0 $A1 >> .git/info/grafts &&
+ git rev-list -1 HEAD 2>&1 | grep "$duplicate_error"
+'
+
test_done
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply related
* Re: Feature request: Store comments on branches
From: Thomas Adam @ 2009-10-21 13:46 UTC (permalink / raw)
To: Patrick Schoenfeld; +Cc: git
In-Reply-To: <20091021133702.GA470@lisa>
2009/10/21 Patrick Schoenfeld <schoenfeld@debian.org>:
> What do others think about this? Would this be useful
> for others, too?
This feature is already being worked on as "git notes" -- see the "pu"
branch, I think it's still in there, unless it has graduated to next;
I forget now.
-- Thomas Adam
^ permalink raw reply
* Re: Feature request: Store comments on branches
From: Howard Miller @ 2009-10-21 13:48 UTC (permalink / raw)
To: Patrick Schoenfeld; +Cc: git
In-Reply-To: <20091021133702.GA470@lisa>
2009/10/21 Patrick Schoenfeld <schoenfeld@debian.org>:
> Hi,
>
> I regulary work with various branches, that I call by the number
> of an associated bug tracking / support tracking number. That
> makes it clear to which ticket a given branch belongs.
> In this case I would find it very useful, if I could associate
> short comments with a branch, which would be shown when
> doing a 'git branch'. This way I could see what this branch
> about, without looking up the ticket information.
>
> Obvious the workaround is to name the branches different,
> but this is sometimes not convenient and may result in quiet
> long branch names.
>
> What do others think about this? Would this be useful
> for others, too?
Definitely +1.
Even on a much more simplistic level (and speaking as a relative
newbie) I feel it's an important feature missing. It's terribly easy
in the fog of working on several different projects to remember what
all the branches really are. It is just human nature that you think it
makes perfect sense at the time but in a couple of weeks time you
can't find the branch you want from three or four similar ones. A
comments field for branches would be very helpful.
Howard
^ permalink raw reply
* Re: Finding a commit
From: Daniele Segato @ 2009-10-21 13:55 UTC (permalink / raw)
To: Thomas Rast; +Cc: Soham Mehta, git
In-Reply-To: <200910211437.39166.trast@student.ethz.ch>
On Wed, Oct 21, 2009 at 2:37 PM, Thomas Rast <trast@student.ethz.ch> wrote:
>> Commit -> Tree ---> Blob1, Blob2, Blob3
>>
>> Commit, Trees and Blobs are all identified by sha1
>> the commit should keep information on the author, the "parent"
>> commit(s) and so on..
>> the tree should just keep the "snapshot" of the data..
>>
>> so I think that if you search for the SHA-1 of the tree you should be fine..
>
> Not if you really want to find out if X was cherry-picked into this
> repository, because the tree is the *final state* at that commit,
> which of course includes all preceding changes.
>
> So suppose you have two patches A.diff and B.diff introducing files of
> the same name; then if you combine them into history as
>
> A -- B
>
> the tree state at B has both files, and hence is different from the
> tree state of B' in
>
> B' -- A'
>
> because there it only has the file B.
Yes... obviously...
the tree is the snapshot of a complete data set: so if you apply the
same patch to different data set you get different trees...
thanks for pointing it out.. :)
Regards,
Daniele
^ permalink raw reply
* Re: Feature request: Store comments on branches
From: B Smith-Mannschott @ 2009-10-21 13:56 UTC (permalink / raw)
To: Thomas Adam; +Cc: Patrick Schoenfeld, git
In-Reply-To: <18071eea0910210646l41f18deam8c75f1218df7e25a@mail.gmail.com>
On Wed, Oct 21, 2009 at 15:46, Thomas Adam <thomas.adam22@gmail.com> wrote:
> 2009/10/21 Patrick Schoenfeld <schoenfeld@debian.org>:
>> What do others think about this? Would this be useful
>> for others, too?
>
> This feature is already being worked on as "git notes" -- see the "pu"
> branch, I think it's still in there, unless it has graduated to next;
> I forget now.
Really? I was under the impression that the nodes were meant to
annotate commits, or more generally things with SHA-1 IDs. (commits,
tress, blobs). The SHA-1 ID a branch uses to refer to its HEAD commit
changes with every commit, and the branch itself doesn't have an ID,
just a name.
// Ben
^ permalink raw reply
* Re: Feature request: Store comments on branches
From: Jeff King @ 2009-10-21 14:13 UTC (permalink / raw)
To: B Smith-Mannschott; +Cc: Thomas Adam, Patrick Schoenfeld, git
In-Reply-To: <28c656e20910210656m5ad597b9h7668e33eeb86b096@mail.gmail.com>
On Wed, Oct 21, 2009 at 03:56:51PM +0200, B Smith-Mannschott wrote:
> >> What do others think about this? Would this be useful
> >> for others, too?
> >
> > This feature is already being worked on as "git notes" -- see the "pu"
> > branch, I think it's still in there, unless it has graduated to next;
> > I forget now.
>
> Really? I was under the impression that the nodes were meant to
> annotate commits, or more generally things with SHA-1 IDs. (commits,
> tress, blobs). The SHA-1 ID a branch uses to refer to its HEAD commit
> changes with every commit, and the branch itself doesn't have an ID,
> just a name.
Yes, I think you are right. If I understand the OP, he really just wants
to annotate the refs themselves, not the commits they point to. So you
could probably get away with setting a "branch.$name.description" config
variable and then showing it during "git branch". The downside of such a
scheme is that it is purely local -- there's no way of pushing or
pulling your descriptions (which is maybe a feature, if you are thinking
of the descriptions as something only for you yourself to see).
A related technique is to maintain a separate meta repository which has
a list of branches, their status, etc. This is what Junio does with the
'todo' branch of git.git. The advantage is that it is fully version
controlled, and you can do much more than just set descriptions (e.g.,
'todo' also has scripts for maintaining the list of topic branches,
calculating branch dependencies, building the pu branch, etc). The
disadvantage is that it's a lot more work to set up and maintain.
-Peff
^ 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