* Re: git-difftool
From: Matthieu Moy @ 2009-01-01 17:58 UTC (permalink / raw)
To: David Aguilar; +Cc: git
In-Reply-To: <402731c90812311211p548c49d3p100f79ddee7163b0@mail.gmail.com>
"David Aguilar" <davvid@gmail.com> writes:
> Hmm... in theory, yes, but in practice, no.
> xxdiff is too gimp to handle what 'git diff' hands it =)
As done with "vimdiff" in another message, simply write a one-liner
wrapper script that calls xxdiff $2 $3, and call this wrapper script.
--
Matthieu
^ permalink raw reply
* Re: Extracting a single commit or object
From: Miklos Vajna @ 2009-01-01 18:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: yitzhakbg, git
In-Reply-To: <alpine.DEB.1.00.0901011747580.30769@pacific.mpi-cbg.de>
[-- Attachment #1: Type: text/plain, Size: 422 bytes --]
On Thu, Jan 01, 2009 at 05:52:49PM +0100, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> If you activated bash completion, you can even complete monsters like
> this:
>
> git show \
> v1.5.3:v1.5.3:t/t4013/diff.diff-tree_--cc_--patch-with-stat_--summary_master
Wow, that's really a monster. After removing the first leading v1.5.3:,
it works. (If this is a bash completion bug, I can't reproduce.)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Subject: [PATCH] Documentation/git-merge: deprecated syntax moved to end
From: jidanni @ 2009-01-01 18:41 UTC (permalink / raw)
To: gitster; +Cc: git
Moving the deprecated syntax moved to the end of the document.
Or please at least stamp it *deprecated* in the SYNOPSIS, in case the
user reads no further down the page.
Signed-off-by: jidanni <jidanni@jidanni.org>
---
Documentation/git-merge.txt | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index a3ac828..e619c9f 100644
--- a/Documentation/git-merge.txt
+++ b/Documentation/git-merge.txt
@@ -11,18 +11,12 @@ SYNOPSIS
[verse]
'git merge' [-n] [--stat] [--no-commit] [--squash] [-s <strategy>]...
[-m <msg>] <remote>...
-'git merge' <msg> HEAD <remote>...
DESCRIPTION
-----------
This is the top-level interface to the merge machinery
which drives multiple merge strategy scripts.
-The second syntax (<msg> `HEAD` <remote>) is supported for
-historical reasons. Do not use it from the command line or in
-new scripts. It is the same as `git merge -m <msg> <remote>`.
-
-
OPTIONS
-------
include::merge-options.txt[]
@@ -211,6 +205,12 @@ You can work through the conflict with a number of tools:
common ancestor, 'git show :2:filename' shows the HEAD
version and 'git show :3:filename' shows the remote version.
+DEPRECATED SYNTAX
+-----------------
+There also as a `git merge <msg> HEAD <remote>...` syntax supported
+for historical reasons. Do not use it from the command line or in new
+scripts. It is the same as `git merge -m <msg> <remote>`.
+
SEE ALSO
--------
linkgit:git-fmt-merge-msg[1], linkgit:git-pull[1],
--
1.6.0.6
^ permalink raw reply related
* [PATCH] Documentation/git-merge: at least one <remote> not two
From: jidanni @ 2009-01-01 18:41 UTC (permalink / raw)
To: gitster; +Cc: git
Make SYNOPSIS match usage message
Signed-off-by: jidanni <jidanni@jidanni.org>
---
Documentation/git-merge.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index f7be584..a3ac828 100644
--- a/Documentation/git-merge.txt
+++ b/Documentation/git-merge.txt
@@ -10,7 +10,7 @@ SYNOPSIS
--------
[verse]
'git merge' [-n] [--stat] [--no-commit] [--squash] [-s <strategy>]...
- [-m <msg>] <remote> <remote>...
+ [-m <msg>] <remote>...
'git merge' <msg> HEAD <remote>...
DESCRIPTION
--
1.6.0.6
^ permalink raw reply related
* got wet with make --dry-run
From: jidanni @ 2009-01-01 17:03 UTC (permalink / raw)
To: git
Gentlemen, make --dry-run is booby trapped to still execute commands:
$ (cd Documentation; make --dry-run); find -mtime -1 -type f
./Documentation/doc.dep
./GIT-VERSION-FILE
Forgot $(MAKEFLAGS)? (info "(make)Options/Recursion").
By the way, why would an offline make need
/bin/sh: curl-config: command not found
^ permalink raw reply
* Re: [PATCH] Documentation/git-bundle.txt: Dumping contents of any bundle
From: Jeff King @ 2009-01-01 19:21 UTC (permalink / raw)
To: jidanni; +Cc: Nicolas Pitre, gitster, mdl123, spearce, git
In-Reply-To: <87prj7mz50.fsf_-_@jidanni.org>
On Thu, Jan 01, 2009 at 12:24:59PM +0800, jidanni@jidanni.org wrote:
> JK> AFAIK, there is no tool to try salvaging strings from an incomplete pack
> JK> (and you can't just run "strings" because the deltas are zlib
> JK> compressed). So if I were in the police forensics department, I think I
> JK> would read Documentation/technical/pack-format.txt and start hacking a
> JK> solution as quickly as possible.
>
> Hogwash. Patch follows. Maybe even better methods are available.
> [...]
> +$ sed '/^PACK/,$!d' mybundle.bun > mybundle.pack
> +$ git unpack-objects < mybundle.pack
> +$ cd .git/objects
> +$ ls ??/*|tr -d /|git cat-file --batch-check
> +$ ls ??/*|tr -d /|git cat-file --batch
Sorry, no, but your method does not work in the case I described: a thin
pack with deltas. In that case, git unpack-objects cannot unpack the
object since it lacks the delta, and will skip it. For example:
# create a bundle with a thin delta blob
mkdir one && cd one && git init
cp /usr/share/dict/words . && git add words && git commit -m one
echo SECRET MESSAGE >>words && git add words && git commit -m two
git bundle create ../mybundle.bun HEAD^..
# now try to fetch from it
mkdir ../two && cd ../two && git init
git bundle unbundle ../mybundle.bun
# produces:
# error: Repository lacks these prerequisite commits:
# error: b7d1a0ca98ca0e997d4222459d6fc1c9edae6a3f one
# so try to recover
sed '/^PACK/,$!d' ../mybundle.bun > mybundle.pack
git unpack-objects < mybundle.pack
# Unpacking objects: 100% (3/3), done.
# fatal: unresolved deltas left after unpacking
cd .git/objects
# this will show just two objects: the commit and the tree
ls ??/* | tr -d /
# confirm that we don't have the blob or the string of interest
ls ??/* | tr -d / | git cat-file --batch | grep SECRET
It is nice that unpack-objects continues at all thanks to the recent
improvements by Nicolas, so you may be able to get some of the data out.
But it just skips over any unresolvable deltas, since we can't make a
useful object from them. Maybe it would be worth adding an option to
dump the uncompressed deltas to a file or directory so you could run
"strings" on them to recover some of the data.
-Peff
^ permalink raw reply
* Re: got wet with make --dry-run
From: Thomas Rast @ 2009-01-01 19:44 UTC (permalink / raw)
To: jidanni; +Cc: git
In-Reply-To: <87eizn0xhd.fsf@jidanni.org>
[-- Attachment #1: Type: text/plain, Size: 1397 bytes --]
jidanni@jidanni.org wrote:
> Gentlemen, make --dry-run is booby trapped to still execute commands:
> $ (cd Documentation; make --dry-run); find -mtime -1 -type f
> ./Documentation/doc.dep
> ./GIT-VERSION-FILE
> Forgot $(MAKEFLAGS)? (info "(make)Options/Recursion").
A two minute check into Makefile shows that the recursion is
implemented via $(MAKE), which is the recommended way to do it. It's
impossible to "forget" $(MAKEFLAGS), since the docs clearly say that
it is always exported unless explicitly unexported.
The *real* reason why it rebuilds GIT-VERSION-FILE is that the
Makefile says '-include GIT-VERSION-FILE', and uses the version info
to decide some parts of the build process. (It'll also do a similar
thing with the $CFLAGS detection code.) Since this influences the
actual commands executed, it seems sensible to run them even under
'make -n'.
> By the way, why would an offline make need
> /bin/sh: curl-config: command not found
From somewhere near the top of Makefile, which is definitely a
recommended read:
# Define NO_CURL if you do not have libcurl installed. git-http-pull and
# git-http-push are not built, and you cannot use http:// and https://
# transports.
Next time please take the time to investigate at least a little bit
into your "issues" before starting to cry foul.
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 0/3] Teach Git about the patience diff algorithm
From: Linus Torvalds @ 2009-01-01 19:45 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Pierre Habouzit, davidel, Francis Galiegue, Git ML
In-Reply-To: <alpine.DEB.1.00.0901011730190.30769@pacific.mpi-cbg.de>
On Thu, 1 Jan 2009, Johannes Schindelin wrote:
>
> Nothing fancy, really, just a straight-forward implementation of the
> heavily under-documented and under-analyzed paience diff algorithm.
Exactly because the patience diff is so under-documented, could you
perhaps give a few examples of how it differs in the result, and why it's
so wonderful? Yes, yes, I can google, and no, no, nothing useful shows up
except for *totally* content-free fanboisms.
So could we have some actual real data on it?
Linus
^ permalink raw reply
* Re: git has modified files after clean checkout
From: Thomas Rast @ 2009-01-01 19:48 UTC (permalink / raw)
To: Caleb Cushing; +Cc: David Aguilar, git
In-Reply-To: <81bfc67a0901010048l7a4a8fa1h42f7cd448dfc704@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 662 bytes --]
Caleb Cushing wrote:
> > The files you mention contain CRLF. Do you have core.autocrlf set
> > globally somewhere, perhaps in your ~/.gitconfig?
>
> yes I have it set to input
Do you have any .gitattributes? A few days ago, ludde on IRC bumped
into the problem that git-checkout applies the .gitattributes that are
present in the tree *before* the checkout. Naturally this means that
the .gitattributes do not apply at all during the first checkout at
the end of cloning. In ludde's case, this caused git-blame to think
the file had all line endings changed compared to the index version.
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 0/3] Teach Git about the patience diff algorithm
From: Linus Torvalds @ 2009-01-01 20:00 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Pierre Habouzit, davidel, Francis Galiegue, Git ML
In-Reply-To: <alpine.LFD.2.00.0901011134210.5086@localhost.localdomain>
On Thu, 1 Jan 2009, Linus Torvalds wrote:
>
> So could we have some actual real data on it?
.. and some testing. I tried to get some limited data for the kernel
myself, by doing
git log --patience -p v2.6.28.. > ~/patience
but I just got a core-dump instead.
Pinpointing it to a specific commit shows a smaller failure case:
git show -p --patience 05d564fe00c05bf8ff93948057ca1acb5bc68e10
which might help you debug this.
Linus
---
#0 0x00000000004cce73 in xdl_get_rec (xdf=0x7fffcb1e08d0, ri=-9, rec=0x7fffcb1e0778) at xdiff/xemit.c:36
#1 0x00000000004cced1 in xdl_emit_record (xdf=0x7fffcb1e08d0, ri=-9, pre=0x4eef79 "-", ecb=0x7fffcb1e0bc0)
at xdiff/xemit.c:46
#2 0x00000000004cd4e6 in xdl_emit_diff (xe=0x7fffcb1e08d0, xscr=0x1111daf0, ecb=0x7fffcb1e0bc0,
xecfg=0x7fffcb1e0b80) at xdiff/xemit.c:179
#3 0x00000000004caa2c in xdl_diff (mf1=0x7fffcb1e0a40, mf2=0x7fffcb1e0a30, xpp=0x7fffcb1e0bd0,
xecfg=0x7fffcb1e0b80, ecb=0x7fffcb1e0bc0) at xdiff/xdiffi.c:559
#4 0x00000000004c088d in xdi_diff (mf1=0x7fffcb1e0c00, mf2=0x7fffcb1e0bf0, xpp=0x7fffcb1e0bd0,
xecfg=0x7fffcb1e0b80, xecb=0x7fffcb1e0bc0) at xdiff-interface.c:137
#5 0x00000000004c0914 in xdi_diff_outf (mf1=0x7fffcb1e0c00, mf2=0x7fffcb1e0bf0, fn=0x475448 <fn_out_consume>,
consume_callback_data=0x7fffcb1e0b40, xpp=0x7fffcb1e0bd0, xecfg=0x7fffcb1e0b80, xecb=0x7fffcb1e0bc0)
at xdiff-interface.c:154
#6 0x00000000004780dc in builtin_diff (name_a=0x25cf6f0 "fs/nfs/nfs4xdr.c", name_b=0x25cf6f0 "fs/nfs/nfs4xdr.c",
one=0x25cf690, two=0x26ae110, xfrm_msg=0xf659900 "index 7dde309..29656c5 100644", o=0x7fffcb1e1088,
complete_rewrite=0) at diff.c:1486
#7 0x00000000004796e4 in run_diff_cmd (pgm=0x0, name=0x25cf6f0 "fs/nfs/nfs4xdr.c", other=0x0,
attr_path=0x25cf6f0 "fs/nfs/nfs4xdr.c", one=0x25cf690, two=0x26ae110,
xfrm_msg=0xf659900 "index 7dde309..29656c5 100644", o=0x7fffcb1e1088, complete_rewrite=0) at diff.c:2024
#8 0x0000000000479e2e in run_diff (p=0xaffece0, o=0x7fffcb1e1088) at diff.c:2158
#9 0x000000000047b959 in diff_flush_patch (p=0xaffece0, o=0x7fffcb1e1088) at diff.c:2743
#10 0x000000000047c942 in diff_flush (options=0x7fffcb1e1088) at diff.c:3184
#11 0x0000000000488b75 in log_tree_diff_flush (opt=0x7fffcb1e0f40) at log-tree.c:451
#12 0x0000000000488d17 in log_tree_diff (opt=0x7fffcb1e0f40, commit=0x2673198, log=0x7fffcb1e0ec0) at log-tree.c:503
#13 0x0000000000488da4 in log_tree_commit (opt=0x7fffcb1e0f40, commit=0x2673198) at log-tree.c:526
#14 0x000000000043218d in cmd_log_walk (rev=0x7fffcb1e0f40) at builtin-log.c:201
#15 0x0000000000432bae in cmd_log (argc=4, argv=0x7fffcb1e14b0, prefix=0x0) at builtin-log.c:423
#16 0x000000000040486b in run_command (p=0x70c7b0, argc=4, argv=0x7fffcb1e14b0) at git.c:243
#17 0x0000000000404a1c in handle_internal_command (argc=4, argv=0x7fffcb1e14b0) at git.c:387
#18 0x0000000000404c6e in main (argc=4, argv=0x7fffcb1e14b0) at git.c:484
^ permalink raw reply
* Re: why still no empty directory support in git
From: Jeff King @ 2009-01-01 20:06 UTC (permalink / raw)
To: Asheesh Laroia; +Cc: Git Mailing List
In-Reply-To: <alpine.DEB.2.00.0812300346040.19911@vellum.laroia.net>
On Tue, Dec 30, 2008 at 03:58:46AM -0500, Asheesh Laroia wrote:
> So, let's say I take your suggestion.
>
> $ touch ~/Maildir/new/.exists
> $ git add ~/Maildir/new/.exists && git commit -m "La di da"
>
> Now a spec-compliant Maildir user agent will attempt to deliver this new
> "email message" of zero bytes into the mail spool and assign it a message
> UID. Doing so will remove it from Maildir/new.
No. The maildir spec says:
A unique name can be anything that doesn't contain a colon (or slash)
and doesn't start with a dot.
-- http://cr.yp.to/proto/maildir.html
where a "unique name" is the filename used for a message. In practice,
every maildir implementation I have seen ignores files starting with a
dot. Do you have one that doesn't?
-Peff
^ permalink raw reply
* Re: [PATCH 0/3] Teach Git about the patience diff algorithm
From: Adeodato Simó @ 2009-01-01 20:46 UTC (permalink / raw)
To: Linus Torvalds
Cc: Johannes Schindelin, Pierre Habouzit, davidel, Francis Galiegue,
Git ML
In-Reply-To: <alpine.LFD.2.00.0901011134210.5086@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 4390 bytes --]
* Linus Torvalds [Thu, 01 Jan 2009 11:45:21 -0800]:
> On Thu, 1 Jan 2009, Johannes Schindelin wrote:
> > Nothing fancy, really, just a straight-forward implementation of the
> > heavily under-documented and under-analyzed paience diff algorithm.
> Exactly because the patience diff is so under-documented, could you
> perhaps give a few examples of how it differs in the result, and why it's
> so wonderful? Yes, yes, I can google, and no, no, nothing useful shows up
> except for *totally* content-free fanboisms.
> So could we have some actual real data on it?
For me, the cases where I find patience output to be of substantial
higher readability are those involving a rewrite of several consecutive
paragraphs (i.e., lines of code separated by blank lines). Compare:
-8<- git -8<-
@@ -51,29 +51,30 @@ def mbox_update(bug):
f.close()
else:
# make a list of Message-Id we have
- fp1 = file(path, 'ab+')
- ids1 = [ x.get('Message-Id') for x in mailbox.UnixMailbox(fp1) ]
+ msgids = { x.get('Message-Id') for x in mailbox.mbox(path) }
- # get remote mbox again
- fp2 = tempfile.TemporaryFile()
- retrieve_mbox(bug, fp2)
+ with tempfile.NamedTemporaryFile() as tmpfd:
+ # retrieve the remote mbox again
+ retrieve_mbox(bug, tmpfd)
- # parse its messages
- fp2.seek(0)
- parser = email.Parser.Parser()
- msgs2 = dict((x['Message-Id'], x)
- for x in mailbox.UnixMailbox(fp2, parser.parse))
+ # parse its messages
+ parser = email.parser.Parser()
+ new_msgids = { x['Message-Id']: x
+ for x in mailbox.mbox(tmpfd.name, parser.parse) }
- # now append the new ones
- for msgid in set(msgs2.keys()) - set(ids1):
- fp1.write('\n' + msgs2[msgid].as_string(unixfrom=True))
+ with open(path, 'a+') as fd:
+ # now append the new messages
+ for msgid in new_msgids.keys() - msgids:
+ fd.write('\n' + new_msgids[msgid].as_string(unixfrom=True))
return path
->8- git ->8-
with:
-8<- bzr patience -8<-
@@ -51,29 +51,30 @@
f.close()
else:
# make a list of Message-Id we have
- fp1 = file(path, 'ab+')
- ids1 = [ x.get('Message-Id') for x in mailbox.UnixMailbox(fp1) ]
-
- # get remote mbox again
- fp2 = tempfile.TemporaryFile()
- retrieve_mbox(bug, fp2)
-
- # parse its messages
- fp2.seek(0)
- parser = email.Parser.Parser()
- msgs2 = dict((x['Message-Id'], x)
- for x in mailbox.UnixMailbox(fp2, parser.parse))
-
- # now append the new ones
- for msgid in set(msgs2.keys()) - set(ids1):
- fp1.write('\n' + msgs2[msgid].as_string(unixfrom=True))
+ msgids = { x.get('Message-Id') for x in mailbox.mbox(path) }
+
+ with tempfile.NamedTemporaryFile() as tmpfd:
+ # retrieve the remote mbox again
+ retrieve_mbox(bug, tmpfd)
+
+ # parse its messages
+ parser = email.parser.Parser()
+ new_msgids = { x['Message-Id']: x
+ for x in mailbox.mbox(tmpfd.name, parser.parse) }
+
+ with open(path, 'a+') as fd:
+ # now append the new messages
+ for msgid in new_msgids.keys() - msgids:
+ fd.write('\n' + new_msgids[msgid].as_string(unixfrom=True))
return path
->8- bzr patience ->8-
I don't know about you, but I find the latter much easier to read,
because the whole context of each version is always available.
As you see, in (at least) this case is just a matter of considering the
blank lines worthy of presented as common, or not.
I'll note that in this particular case, `git diff` yielded the very same
results with or without --patience. I don't know why that is, Johannes?
I'll also note that /usr/bin/diff produces (in this case) something
closer to patience than to git.
I'm attaching both versions of the file in case they are useful to
anybody.
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
I promise you. Once I enter into an exclusive relationship, I sleep with
very few people.
-- Denny Crane
[-- Attachment #2: bdo0 --]
[-- Type: text/plain, Size: 2358 bytes --]
#! /usr/bin/python
## vim: fileencoding=utf-8
"""Open Debian BTS mboxes with Mutt, à la /usr/bin/bts show --mbox.
A cache of mboxes is kept, and changed mboxes will be merged with existing
files instead of replacing them, so that e.g. read-status is preserved for each
message.
"""
import os
import re
import sys
import urllib
import mailbox
import tempfile
import email.Parser
MBOX_DIR = os.path.expanduser('~/.mail/y.bug-cache')
##
def main():
if len(sys.argv) != 2:
print >>sys.stderr, 'Usage: %s <bugnumber>' % (sys.argv[0],)
sys.exit(1)
bug = re.sub(r'[^0-9]', '', sys.argv[1])
if not re.match(r'\d{4,}$', bug):
print >>sys.stderr, \
'E: %s does not seem a valid number' % (sys.argv[1],)
sys.exit(1)
path = mbox_update(bug)
invoke_mailer(path)
##
def mbox_update(bug):
"""Return a path with an up-to-date copy of the mbox for bug."""
path = os.path.join(MBOX_DIR, bug + '.mbox')
if not os.path.exists(path):
f = file(path, 'wb')
try:
retrieve_mbox(bug, f)
except:
os.unlink(path)
raise
else:
f.close()
else:
# make a list of Message-Id we have
fp1 = file(path, 'ab+')
ids1 = [ x.get('Message-Id') for x in mailbox.UnixMailbox(fp1) ]
# get remote mbox again
fp2 = tempfile.TemporaryFile()
retrieve_mbox(bug, fp2)
# parse its messages
fp2.seek(0)
parser = email.Parser.Parser()
msgs2 = dict((x['Message-Id'], x)
for x in mailbox.UnixMailbox(fp2, parser.parse))
# now append the new ones
for msgid in set(msgs2.keys()) - set(ids1):
fp1.write('\n' + msgs2[msgid].as_string(unixfrom=True))
return path
def retrieve_mbox(bug, fileobj):
"""Retrieve mbox for bug from bugs.debian.org, writing it to fileobj."""
for line in urllib.urlopen(
'http://bugs.debian.org/cgi-bin/bugreport.cgi?mboxstatus=yes;mboxmaint=yes;mbox=yes;bug=%s' % (bug,)):
fileobj.write(line)
def invoke_mailer(path):
"""Exec mutt, opening path."""
os.execlp('mutt', 'mutt', '-f', path)
##
if __name__ == '__main__':
try:
sys.exit(main())
except KeyboardInterrupt:
print >>sys.stderr, '\nCancelled.'
sys.exit(1)
[-- Attachment #3: bdo1 --]
[-- Type: text/plain, Size: 2501 bytes --]
#! /usr/bin/python3
"""Open Debian BTS mboxes with Mutt, à la /usr/bin/bts show --mbox.
A cache of mboxes is kept, and changed mboxes will be merged with existing
files instead of replacing them, so that e.g. read-status is preserved for each
message.
"""
import os
import re
import sys
import mailbox
import tempfile
import email.parser
import urllib.request
MBOX_DIR = os.path.expanduser('~/.mail/y.bug-cache')
##
def main():
if len(sys.argv) != 2:
print('Usage: {0} <bugnumber>'.format(sys.argv[0]), file=sys.stderr)
return 1
else:
bug = re.sub(r'[^0-9]', '', sys.argv[1])
if not re.search(r'^\d{4,}$', bug):
print('E: {0} does not seem a valid number'.format(sys.argv[1]),
file=sys.stderr)
return 1
path = mbox_update(bug)
invoke_mailer(path)
##
def mbox_update(bug):
"""Return a path with an up-to-date copy of the mbox for bug."""
path = os.path.join(MBOX_DIR, bug + '.mbox')
if not os.path.exists(path):
f = open(path, 'wb')
try:
retrieve_mbox(bug, f)
except:
os.unlink(path)
raise
else:
f.close()
else:
# make a list of Message-Id we have
msgids = { x.get('Message-Id') for x in mailbox.mbox(path) }
with tempfile.NamedTemporaryFile() as tmpfd:
# retrieve the remote mbox again
retrieve_mbox(bug, tmpfd)
# parse its messages
parser = email.parser.Parser()
new_msgids = { x['Message-Id']: x
for x in mailbox.mbox(tmpfd.name, parser.parse) }
with open(path, 'a+') as fd:
# now append the new messages
for msgid in new_msgids.keys() - msgids:
fd.write('\n' + new_msgids[msgid].as_string(unixfrom=True))
return path
def retrieve_mbox(bug, fileobj):
"""Retrieve mbox for bug from bugs.debian.org, writing it to fileobj."""
url = urllib.request.urlopen(
'http://bugs.debian.org/cgi-bin/bugreport.cgi?'
'mboxstatus=yes;mboxmaint=yes;mbox=yes;bug={0}'.format(bug))
for line in url.fp: # http://bugs.python.org/issue4608
fileobj.write(line)
def invoke_mailer(path):
"""Exec mutt, opening path."""
os.execlp('mutt', 'mutt', '-f', path)
##
if __name__ == '__main__':
try:
sys.exit(main())
except KeyboardInterrupt:
print('\nCancelled.', file=sys.stderr)
sys.exit(1)
^ permalink raw reply
* unpack-trees: fix D/F conflict bugs in verify_absent
From: Clemens Buchacher @ 2009-01-01 20:54 UTC (permalink / raw)
To: git; +Cc: gitster
I came across a few bugs while investigating the changes I proposed in the
modify/delete conflict thread. The first two are quite obvious. The third I'm
not so sure about. I could not find a testcase where it matters. Junio, do you
recall the original intention of that code?
[PATCH 1/3] unpack-trees: handle failure in verify_absent
[PATCH 2/3] unpack-trees: fix path search bug in verify_absent
[PATCH 3/3] unpack-trees: remove redundant path search in verify_absent
t/t1001-read-tree-m-2way.sh | 51 +++++++++++++++++++++++++++++++++++++++++++
unpack-trees.c | 37 +++++++++++++++----------------
2 files changed, 69 insertions(+), 19 deletions(-)
^ permalink raw reply
* [PATCH 1/3] unpack-trees: handle failure in verify_absent
From: Clemens Buchacher @ 2009-01-01 20:54 UTC (permalink / raw)
To: git; +Cc: gitster, Clemens Buchacher
In-Reply-To: <1230843273-11056-1-git-send-email-drizzd@aon.at>
Commit 203a2fe1 (Allow callers of unpack_trees() to handle failure)
changed the "die on error" behavior to "return failure code".
verify_absent did not handle errors returned by
verify_clean_subdirectory, however.
---
t/t1001-read-tree-m-2way.sh | 24 ++++++++++++++++++++++++
unpack-trees.c | 8 +++++---
2 files changed, 29 insertions(+), 3 deletions(-)
diff --git a/t/t1001-read-tree-m-2way.sh b/t/t1001-read-tree-m-2way.sh
index 4b44e13..7f6ab31 100755
--- a/t/t1001-read-tree-m-2way.sh
+++ b/t/t1001-read-tree-m-2way.sh
@@ -341,4 +341,28 @@ test_expect_success \
check_cache_at DF/DF dirty &&
:'
+test_expect_success \
+ 'a/b (untracked) vs a case setup.' \
+ 'rm -f .git/index &&
+ : >a &&
+ git update-index --add a &&
+ treeM=`git write-tree` &&
+ echo treeM $treeM &&
+ git ls-tree $treeM &&
+ git ls-files --stage >treeM.out &&
+
+ rm -f a &&
+ git update-index --remove a &&
+ mkdir a &&
+ : >a/b &&
+ treeH=`git write-tree` &&
+ echo treeH $treeH &&
+ git ls-tree $treeH'
+
+test_expect_success \
+ 'a/b (untracked) vs a, plus c/d case test.' \
+ '! git read-tree -u -m "$treeH" "$treeM" &&
+ git ls-files --stage &&
+ test -f a/b'
+
test_done
diff --git a/unpack-trees.c b/unpack-trees.c
index 54f301d..a736947 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -588,7 +588,7 @@ static int verify_absent(struct cache_entry *ce, const char *action,
return 0;
if (!lstat(ce->name, &st)) {
- int cnt;
+ int ret;
int dtype = ce_to_dtype(ce);
struct cache_entry *result;
@@ -616,7 +616,9 @@ static int verify_absent(struct cache_entry *ce, const char *action,
* files that are in "foo/" we would lose
* it.
*/
- cnt = verify_clean_subdirectory(ce, action, o);
+ ret = verify_clean_subdirectory(ce, action, o);
+ if (ret < 0)
+ return ret;
/*
* If this removed entries from the index,
@@ -635,7 +637,7 @@ static int verify_absent(struct cache_entry *ce, const char *action,
* We need to increment it by the number of
* deleted entries here.
*/
- o->pos += cnt;
+ o->pos += ret;
return 0;
}
--
1.6.1
^ permalink raw reply related
* [PATCH 2/3] unpack-trees: fix path search bug in verify_absent
From: Clemens Buchacher @ 2009-01-01 20:54 UTC (permalink / raw)
To: git; +Cc: gitster, Clemens Buchacher
In-Reply-To: <1230843273-11056-2-git-send-email-drizzd@aon.at>
Commit 0cf73755 (unpack-trees.c: assume submodules are clean during
check-out) changed an argument to verify_absent from 'path' to 'ce',
which is however shadowed by a local variable of the same name.
The bug triggers if verify_absent is used on a tree entry, for which
the index contains one or more subsequent directories of the same
length. The affected subdirectories are removed from the index. The
testcase included in this commit bisects to 55218834 (checkout: do not
lose staged removal), which reveals the bug in this case, but is
otherwise unrelated.
---
t/t1001-read-tree-m-2way.sh | 27 +++++++++++++++++++++++++++
unpack-trees.c | 23 ++++++++++++-----------
2 files changed, 39 insertions(+), 11 deletions(-)
diff --git a/t/t1001-read-tree-m-2way.sh b/t/t1001-read-tree-m-2way.sh
index 7f6ab31..271bc4e 100755
--- a/t/t1001-read-tree-m-2way.sh
+++ b/t/t1001-read-tree-m-2way.sh
@@ -365,4 +365,31 @@ test_expect_success \
git ls-files --stage &&
test -f a/b'
+test_expect_success \
+ 'a/b vs a, plus c/d case setup.' \
+ 'rm -f .git/index &&
+ rm -fr a &&
+ : >a &&
+ mkdir c &&
+ : >c/d &&
+ git update-index --add a c/d &&
+ treeM=`git write-tree` &&
+ echo treeM $treeM &&
+ git ls-tree $treeM &&
+ git ls-files --stage >treeM.out &&
+
+ rm -f a &&
+ mkdir a
+ : >a/b &&
+ git update-index --add --remove a a/b &&
+ treeH=`git write-tree` &&
+ echo treeH $treeH &&
+ git ls-tree $treeH'
+
+test_expect_success \
+ 'a/b vs a, plus c/d case test.' \
+ 'git read-tree -u -m "$treeH" "$treeM" &&
+ git ls-files --stage | tee >treeMcheck.out &&
+ test_cmp treeM.out treeMcheck.out'
+
test_done
diff --git a/unpack-trees.c b/unpack-trees.c
index a736947..f8e2484 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -289,7 +289,8 @@ static int unpack_nondirectories(int n, unsigned long mask, unsigned long dirmas
return 0;
}
-static int unpack_callback(int n, unsigned long mask, unsigned long dirmask, struct name_entry *names, struct traverse_info *info)
+static int unpack_callback(int n, unsigned long mask, unsigned long dirmask,
+ struct name_entry *names, struct traverse_info *info)
{
struct cache_entry *src[5] = { NULL, };
struct unpack_trees_options *o = info->data;
@@ -517,22 +518,22 @@ static int verify_clean_subdirectory(struct cache_entry *ce, const char *action,
namelen = strlen(ce->name);
pos = index_name_pos(o->src_index, ce->name, namelen);
if (0 <= pos)
- return cnt; /* we have it as nondirectory */
+ return 0; /* we have it as nondirectory */
pos = -pos - 1;
for (i = pos; i < o->src_index->cache_nr; i++) {
- struct cache_entry *ce = o->src_index->cache[i];
- int len = ce_namelen(ce);
+ struct cache_entry *ce2 = o->src_index->cache[i];
+ int len = ce_namelen(ce2);
if (len < namelen ||
- strncmp(ce->name, ce->name, namelen) ||
- ce->name[namelen] != '/')
+ strncmp(ce->name, ce2->name, namelen) ||
+ ce2->name[namelen] != '/')
break;
/*
- * ce->name is an entry in the subdirectory.
+ * ce2->name is an entry in the subdirectory.
*/
- if (!ce_stage(ce)) {
- if (verify_uptodate(ce, o))
+ if (!ce_stage(ce2)) {
+ if (verify_uptodate(ce2, o))
return -1;
- add_entry(o, ce, CE_REMOVE, 0);
+ add_entry(o, ce2, CE_REMOVE, 0);
}
cnt++;
}
@@ -624,7 +625,7 @@ static int verify_absent(struct cache_entry *ce, const char *action,
* If this removed entries from the index,
* what that means is:
*
- * (1) the caller unpack_trees_rec() saw path/foo
+ * (1) the caller unpack_callback() saw path/foo
* in the index, and it has not removed it because
* it thinks it is handling 'path' as blob with
* D/F conflict;
--
1.6.1
^ permalink raw reply related
* Re: [PATCH] Git.pm: let a "false" Directory parameter (such as "0") be used correctly by the constructor"
From: Junio C Hamano @ 2009-01-01 21:00 UTC (permalink / raw)
To: Philippe Bruhat (BooK); +Cc: git
In-Reply-To: <1230510300-7854-1-git-send-email-book@cpan.org>
"Philippe Bruhat (BooK)" <book@cpan.org> writes:
> ---
> perl/Git.pm | 7 ++++---
> 1 files changed, 4 insertions(+), 3 deletions(-)
Lacks sign-off and description but otherwise looks good. Will queue to
'pu' to leave you a chance to re-send.
commit b29b1ae7442cd7c1c78e38b7d980905944ec31e0
Author: Philippe Bruhat (BooK) <book@cpan.org>
Date: Mon Dec 29 01:25:00 2008 +0100
Git.pm: correctly handle directory name that evaluates to "false"
The repository constructor mistakenly rewrote a Directory parameter that
Perl happens to evaluate to false (e.g. "0") to ".".
Thanks.
^ permalink raw reply
* Re: [PATCH] git-cherry: make <upstream> parameter optional
From: Junio C Hamano @ 2009-01-01 21:00 UTC (permalink / raw)
To: markus.heidelberg; +Cc: git
In-Reply-To: <200812291845.20500.markus.heidelberg@web.de>
Markus Heidelberg <markus.heidelberg@web.de> writes:
> diff --git a/Documentation/git-cherry.txt b/Documentation/git-cherry.txt
> index 74d14c4..556ea23 100644
> --- a/Documentation/git-cherry.txt
> +++ b/Documentation/git-cherry.txt
> @@ -7,7 +7,7 @@ git-cherry - Find commits not merged upstream
>
> SYNOPSIS
> --------
> -'git cherry' [-v] <upstream> [<head>] [<limit>]
> +'git cherry' [-v] [<upstream>] [<head>] [<limit>]
Shouldn't this be [<upstream> [<head> [<limit>]]]?
^ permalink raw reply
* Re: [PATCH] Document git-ls-tree --full-tree
From: Junio C Hamano @ 2009-01-01 21:00 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git, Markus Heidelberg
In-Reply-To: <20081231190050.6117@nanako3.lavabit.com>
Thanks.
^ permalink raw reply
* Re: [PATCH,RESEND] objects to be pruned immediately don't have to be loosened
From: Junio C Hamano @ 2009-01-01 21:00 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <alpine.LFD.2.00.0812301441540.30266@xanadu.home>
Thanks. I take this as a usability fix for large repository?
^ permalink raw reply
* Re: [PATCH] Documentation/gitcli.txt: dashed forms not allowed anymore
From: Junio C Hamano @ 2009-01-01 21:00 UTC (permalink / raw)
To: Miklos Vajna; +Cc: jidanni, git
In-Reply-To: <20090101144045.GC21154@genesis.frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> On Thu, Jan 01, 2009 at 12:39:39PM +0800, jidanni@jidanni.org wrote:
>> - * it's preferred to use the non dashed form of git commands, which means that
>> - you should prefer `"git foo"` to `"git-foo"`.
>> + * it's required to use the non dashed form of git commands, which means that
>> + you must use `"git foo"` and not `"git-foo"`. The latter no longer works.
>
> I would append: "unless you add the output of `git --exec-path` to your
> PATH."
I actually wouldn't.
There needs to be a description about use of PATH=$(git --exec-path):$PATH
if you choose to use the dashed forms in your script. Don't we already
have that elsewhere more basic in the documentation set?
The quoted part of the documentation talks about the syntax and convention
used while scripting, and what it wants to say with the sentence is that
the dashless form is preferred, even with PATH=$(git --exec-path):$PATH
(iow, it was preferred before 1.6.0, and it still is preferred with the
$PATH adjustments after 1.6.0).
I think it muddies the point of the list if you talk about the necessity
of $PATH adjustment, which is a irrelevant detail.
^ permalink raw reply
* Re: [PATCH v2 1/3] rebase: learn to rebase root commit
From: Junio C Hamano @ 2009-01-01 21:00 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <7b2902d36a4790670f20f786d4ea2e26052a6e71.1230639970.git.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> Teach git-rebase a new option --root, which instructs it to rebase the
> entire history leading up to <branch>.
>
> The main use-case is with git-svn: suppose you start hacking (perhaps
> offline) on a new project, but later notice you want to commit this
> work to SVN. You will have to rebase the entire history, including
> the root commit, on a (possibly empty) commit coming from git-svn, to
> establish a history connection. This previously had to be done by
> cherry-picking the root commit manually.
I like what this series tries to do. Using the --root option is probably
a more natural way to do what people often do with the "add graft and
filter-branch the whole history once" procedure.
But it somewhat feels sad if the "main" use-case for this is to start your
project in git and then migrate away by feeding your history to subversion
;-).
> @@ -344,17 +348,23 @@ case "$diff" in
> ;;
> esac
>
> +if test -z "$rebase_root"; then
> # The upstream head must be given. Make sure it is valid.
> -upstream_name="$1"
> -upstream=`git rev-parse --verify "${upstream_name}^0"` ||
> - die "invalid upstream $upstream_name"
> + upstream_name="$1"
> + shift
> + upstream=`git rev-parse --verify "${upstream_name}^0"` ||
> + die "invalid upstream $upstream_name"
> +fi
> +
> +test ! -z "$rebase_root" -a -z "$newbase" &&
> + die "--root must be used with --onto"
This is much easier to read if it were:
if test -z "$rebase_root"
then
... do the upstream_name/upstream thing, such as
upstream_name="$1"
...
else
... do the rebase_root thing, including
unset upstream
unset upstream_name
test -z "$newbase" && die "--root without --onto"
...
fi
(Mental note. You shifted positional parameters and the remainders need
to be adjusted, which you seem to have done).
> # Make sure the branch to rebase onto is valid.
> onto_name=${newbase-"$upstream_name"}
> onto=$(git rev-parse --verify "${onto_name}^0") || exit
>
> # If a hook exists, give it a chance to interrupt
> -run_pre_rebase_hook ${1+"$@"}
> +run_pre_rebase_hook ${upstream_name+"$upstream_name"} "$@"
I do not think ${upstream_name+"$upstream_name"} is a good check to begin
with, because presense of it does not necessarily mean the command was
invoked without --root; it could have come from the environment of the
invoker (hence the suggestion to unset the variable explicitly).
And I do not think this is a good way to extend the calling convention of
the hook, either. pre-rebase-hook used to always take upstream and
optionally the explicit branch name. When --root is given, your code will
give the hook a single parameter which is the explicit branch name
(i.e. "we will switch to this branch and rebase it, are you Ok with it?"),
but the hook will mistakenly think you are feeding the fork-point commit.
Because an old pre-rebase-hook cannot verify --root case correctly anyway
and needs to be updated, how about doing 'run_pre_rebase_hook --root "$@"'
when --root was given?
> @@ -393,7 +403,8 @@ case "$#" in
> esac
> orig_head=$branch
>
> -# Now we are rebasing commits $upstream..$branch on top of $onto
> +# Now we are rebasing commits $upstream..$branch (or simply $branch
> +# with --root) on top of $onto
"or simply everything leading to $branch if --root is given"?
> # Check if we are already based on $onto with linear history,
> # but this should be done only when upstream and onto are the same.
> @@ -429,10 +440,18 @@ then
> exit 0
> fi
>
> +if test ! -z "$rebase_root"; then
> + revisions="$orig_head"
> + fp_flag="--root"
> +else
> + revisions="$upstream..$orig_head"
> + fp_flag="--ignore-if-in-upstream"
> +fi
Hmph, the reason why --ignore-if-in-upstream is irrelevant when --root is
given is because...?
> diff --git a/t/t3412-rebase-root.sh b/t/t3412-rebase-root.sh
> new file mode 100755
> index 0000000..63ec5e6
> --- /dev/null
> +++ b/t/t3412-rebase-root.sh
> @@ -0,0 +1,52 @@
> +#!/bin/sh
> +
> +test_description='git rebase --root
> ...
> +test_done
Including tests for the pre-rebase-hook would be nice.
^ permalink raw reply
* Re: [PATCH] Pass --upload-pack and --receive-pack through submodules.
From: Junio C Hamano @ 2009-01-01 21:00 UTC (permalink / raw)
To: Jason Riedy; +Cc: git
In-Reply-To: <1230649782-14710-1-git-send-email-jason@acm.org>
Jason Riedy <jason@acm.org> writes:
> While I no longer have to worry about a zillion ancient OS versions,
> I now have to worry about a remote site where I cannot control the
> path for non-interactive shells. Thus, submodules need to handle
> explicitly specified git-upload-pack and git-receive-pack programs.
Do we (and can we) assume that the remote repositories submodules fetch
from all reside on the same host and can share the same values for these
parameters? Shouldn't these instead be specified in the configuration
files for the submodules, if they need to be nonstandard values?
^ permalink raw reply
* Re: Subject: [PATCH] Documentation/git-merge: deprecated syntax moved to end
From: Junio C Hamano @ 2009-01-01 21:00 UTC (permalink / raw)
To: jidanni; +Cc: git
In-Reply-To: <87bpuqvpfz.fsf@jidanni.org>
jidanni@jidanni.org writes:
> Moving the deprecated syntax moved to the end of the document.
> Or please at least stamp it *deprecated* in the SYNOPSIS, in case the
> user reads no further down the page.
To my mind, there is a difference between something being kept (and will
be kept for foreseeable future), and something being deprecated (and
eventual removal is at least contemplated). The original merge syntax
falls into the first category, and the current description is correct and
fine as-is.
The wording "for historical reasons" does not refer to the reason why the
second syntax is still kept. It merely refers to the reason why two
syntaxes exist in the first place.
^ permalink raw reply
* Re: [PATCH] Documentation/git-merge: at least one <remote> not two
From: Junio C Hamano @ 2009-01-01 21:25 UTC (permalink / raw)
To: jidanni; +Cc: git
In-Reply-To: <87d4f6vph7.fsf@jidanni.org>
jidanni@jidanni.org writes:
> Make SYNOPSIS match usage message
>
> Signed-off-by: jidanni <jidanni@jidanni.org>
> ---
> Documentation/git-merge.txt | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
> index f7be584..a3ac828 100644
> --- a/Documentation/git-merge.txt
> +++ b/Documentation/git-merge.txt
> @@ -10,7 +10,7 @@ SYNOPSIS
> --------
> [verse]
> 'git merge' [-n] [--stat] [--no-commit] [--squash] [-s <strategy>]...
> - [-m <msg>] <remote> <remote>...
> + [-m <msg>] <remote>...
> 'git merge' <msg> HEAD <remote>...
The original uses ellipses for the first-class UI syntax as "zero or
more", while it means "one or more" in the description for the original
syntax, which is inconsistent, and you are matching them by making both
use "one or more" interpretation.
Two issues:
* Are there similar breakages like this in the documentation and the
usage text? It would be a good idea to make the ellipses to mean the
same thing everywhere, and a janitorial patch series that would fix
the "ellipses" breakage (and nothing else) may be a good thing to
have. But before going that route...
* Is it a good idea to standardize on "one or more" semantics? I suspect
we would rather want to standardize on "zero or more", because it would
be more natural to say:
$ git diff [--] <paths>...
to mean "You can give paths if you want to but you do not have to". If
ellipses meant "one or more", you have to say this instead:
$ git diff [--] [<paths>...]
While I prefer "zero or more" because I think it is more logical, if the
preparatory study for the first issue reveals that we use "one or more" a
lot more often, it might be easier to standardize on that interpretation.
Oh, you also need to give ellipses to the usage string for the original
syntax in builtin-merge.c to match SYNOPSIS and usage string.
Thanks.
^ permalink raw reply
* [PATCH 3/3] unpack-trees: remove redundant path search in verify_absent
From: Clemens Buchacher @ 2009-01-01 20:54 UTC (permalink / raw)
To: git; +Cc: gitster, Clemens Buchacher
In-Reply-To: <1230843273-11056-3-git-send-email-drizzd@aon.at>
Since the only caller, verify_absent, relies on the fact that o->pos
points to the next index entry anyways, there is no need to recompute
its position.
Furthermore, if a nondirectory entry were found, this would return too
early, because there could still be an untracked directory in the way.
This is currently not a problem, because verify_absent is only called
if the index does not have this entry.
---
unpack-trees.c | 8 ++------
1 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/unpack-trees.c b/unpack-trees.c
index f8e2484..c4dc6dc 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -495,7 +495,7 @@ static int verify_clean_subdirectory(struct cache_entry *ce, const char *action,
* anything in the existing directory there.
*/
int namelen;
- int pos, i;
+ int i;
struct dir_struct d;
char *pathbuf;
int cnt = 0;
@@ -516,11 +516,7 @@ static int verify_clean_subdirectory(struct cache_entry *ce, const char *action,
* in that directory.
*/
namelen = strlen(ce->name);
- pos = index_name_pos(o->src_index, ce->name, namelen);
- if (0 <= pos)
- return 0; /* we have it as nondirectory */
- pos = -pos - 1;
- for (i = pos; i < o->src_index->cache_nr; i++) {
+ for (i = o->pos; i < o->src_index->cache_nr; i++) {
struct cache_entry *ce2 = o->src_index->cache[i];
int len = ce_namelen(ce2);
if (len < namelen ||
--
1.6.1
^ permalink raw reply related
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