* Re: [PATCH] Documentation/git-push.txt: fix typo in remote tracking branch path
From: Brandon Casey @ 2012-11-27 1:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git@vger.kernel.org, Brandon Casey
In-Reply-To: <7vy5hnomsl.fsf@alter.siamese.dyndns.org>
On 11/26/2012 5:30 PM, Junio C Hamano wrote:
> Brandon Casey <bcasey@nvidia.com> writes:
>
>> From: Brandon Casey <drafnel@gmail.com>
>>
>> This example in the documentation seems to be trying to describe the likely
>> remote tracking branch that will be updated by a push to the "origin" remote
>> with the destination branch 'satellite/master', but it forgot to specify
>> the remote name in the path specification.
>>
>> So,
>>
>> refs/remotes/satellite/master
>>
>> should be spelled like
>>
>> refs/remotes/origin/satellite/master
>
> I might make sense to rename 'origin' to 'mothership' in that
> example and explain that this is emulating 'git fetch' run on the
> mothership to integrate the work done on 'satellite' using 'git
> push' in the opposite direction, which is often necessary when you
> can only make connection in one way (i.e. satellite can ssh into
> mothership but mothership cannot initiate connection to satellite
> because the latter is behind a firewall or does not run sshd).
>
> If you were to run 'git fetch' on the mothership to intgrate the
> work on the 'satellite', it would have a remote called 'satellite',
> and would keep remote-tracking branches for the branches local to
> 'satellite' in the 'refs/remotes/satellite/' hierarchy. You would
> push your local 'master' to their 'refs/remotes/satellite/master',
> to emulate 'git fetch' done on the mothership in the reverse
> direction.
>
> So refs are correct. The context is not sufficiently explained.
Ah, I see. Yeah, I think that is complex enough to merit an
extended explanation.
-Brandon
-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information. Any unauthorized review, use, disclosure or distribution
is prohibited. If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
^ permalink raw reply
* Re: [PATCH 1/7] push: return reject reasons via a mask
From: Chris Rorvick @ 2012-11-27 3:00 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Angelo Borsotti, Drew Northup, Michael Haggerty,
Philip Oakley, Johannes Sixt, Kacper Kornet, Jeff King,
Felipe Contreras
In-Reply-To: <7vobikryrc.fsf@alter.siamese.dyndns.org>
On Mon, Nov 26, 2012 at 12:43 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Chris Rorvick <chris@rorvick.com> writes:
>
>> Pass all rejection reasons back from transport_push(). The logic is
>> simpler and more flexible with regard to providing useful feedback.
>>
>> Signed-off-by: Chris Rorvick <chris@rorvick.com>
>> ---
>
> In any case, naming it as "reject_mask" is like calling a counter as
> "counter_int". It is more important to name it after its purpose
> than after its type
Agreed.
> and because this is to record the reasons why
> the push was rejected, "rejection_reason" might be a better name for
> it.
Yes, that is better for all the reasons you mention. I will fix this up.
^ permalink raw reply
* Re: [PATCH 7/7] push: clarify rejection of update to non-commit-ish
From: Chris Rorvick @ 2012-11-27 3:52 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Angelo Borsotti, Drew Northup, Michael Haggerty,
Philip Oakley, Johannes Sixt, Kacper Kornet, Jeff King,
Felipe Contreras
In-Reply-To: <7vk3t8ryap.fsf@alter.siamese.dyndns.org>
On Mon, Nov 26, 2012 at 12:53 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Chris Rorvick <chris@rorvick.com> writes:
>
>> Pushes must already (by default) update to a commit-ish due the fast-
>> forward check in set_ref_status_for_push(). But rejecting for not being
>> a fast-forward suggests the situation can be resolved with a merge.
>> Flag these updates (i.e., to a blob or a tree) as not forwardable so the
>> user is presented with more appropriate advice.
>>
>> Signed-off-by: Chris Rorvick <chris@rorvick.com>
>> ---
>> remote.c | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/remote.c b/remote.c
>> index f5bc4e7..ee0c1e5 100644
>> --- a/remote.c
>> +++ b/remote.c
>> @@ -1291,6 +1291,11 @@ static inline int is_forwardable(struct ref* ref)
>> if (!o || o->type != OBJ_COMMIT)
>> return 0;
>>
>> + /* new object must be commit-ish */
>> + o = deref_tag(parse_object(ref->new_sha1), NULL, 0);
>> + if (!o || o->type != OBJ_COMMIT)
>> + return 0;
>> +
>
> I think the original code used ref_newer() which took commit-ish on
> both sides.
That is still called later in set_ref_status_for_push() to calculate
the nonfastforward flag. The only reason for even checking the new
here is to exclude trees and blobs now so they are flagged as
already-existing and thus avoid nonsensical fetch-and-merge advice.
Otherwise the behavior is unchanged by this last patch.
ref_newer() does end up redoing computation now done in the new
is_forwardable() function. I could probably factor this out of
ref_newer() into a commit_newer() function that could be reused in
set_ref_status_for_push() to avoid this overhead, but it didn't seem
like a big deal. Thoughts?
> With this code, the old must be a commit but new can be a tag that
> points at a commit? Why?
The old must not be a tag because fast-forwarding from it is
potentially destructive; a tag would likely be left dangling in this
case. This is not true for the new, though. I'm not sure
fast-forwarding from a commit to a tag is useful, but I didn't see a
reason to prevent it either. The refs/tags/ hierarchy is excluded
from fast-forwarding before this check, and refs/heads/ is already
protected against anything but commits. So it seems very unlikely
that someone would accidentally make use of this behavior.
So, fast-forwarding to a tag seemed fairly benign and unlikely to
cause confusion, so I leaned towards allowing it in case someone found
a use case for it.
^ permalink raw reply
* [PATCH] Support for git aliasing for tcsh completion
From: Marc Khouzam @ 2012-11-27 4:13 UTC (permalink / raw)
To: git, Felipe Contreras, SZEDER Gábor; +Cc: Tuncer Ayaz
In-Reply-To: <1353989472-4142-1-git-send-email-marc.khouzam@gmail.com>
tcsh users sometimes alias the 'git' command to another name. In
this case, the user expects to only have to issue a new 'complete'
command using the alias name.
However, the tcsh script currently uses the command typed by the
user to call the appropriate function in git-completion.bash, either
_git() or _gitk(). When using an alias, this technique no longer
works.
This change specifies the real name of the command (either 'git' or
'gitk') as a parameter to the script handling tcsh completion. This
allows the user to use any alias for the 'git' or 'gitk' commands,
while still getting completion to work.
A check for the presence of ${HOME}/.git-completion.bash is also
added to help the user make use of the script properly.
Signed-off-by: Marc Khouzam <marc.khouzam@gmail.com>
---
This issue was reported by someone already making use of the tcsh
completion script.
Thanks for considering this fix.
Marc
contrib/completion/git-completion.tcsh | 19 ++++++++++++-------
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/contrib/completion/git-completion.tcsh
b/contrib/completion/git-completion.tcsh
index dc5678c..44bd544 100644
--- a/contrib/completion/git-completion.tcsh
+++ b/contrib/completion/git-completion.tcsh
@@ -23,6 +23,12 @@
set __git_tcsh_completion_original_script = ${HOME}/.git-completion.bash
set __git_tcsh_completion_script = ${HOME}/.git-completion.tcsh.bash
+# Check that the user put the script in the right place
+if ( ! -e ${__git_tcsh_completion_original_script} ) then
+ echo "git-completion.tcsh: Cannot find:
${__git_tcsh_completion_original_script}. Git completion will not work."
+ exit
+endif
+
cat << EOF > ${__git_tcsh_completion_script}
#!bash
#
@@ -34,13 +40,13 @@ cat << EOF > ${__git_tcsh_completion_script}
source ${__git_tcsh_completion_original_script}
# Set COMP_WORDS in a way that can be handled by the bash script.
-COMP_WORDS=(\$1)
+COMP_WORDS=(\$2)
# The cursor is at the end of parameter #1.
# We must check for a space as the last character which will
# tell us that the previous word is complete and the cursor
# is on the next word.
-if [ "\${1: -1}" == " " ]; then
+if [ "\${2: -1}" == " " ]; then
# The last character is a space, so our location is at the end
# of the command-line array
COMP_CWORD=\${#COMP_WORDS[@]}
@@ -51,13 +57,12 @@ else
COMP_CWORD=\$((\${#COMP_WORDS[@]}-1))
fi
-# Call _git() or _gitk() of the bash script, based on the first
-# element of the command-line
-_\${COMP_WORDS[0]}
+# Call _git() or _gitk() of the bash script, based on the first argument
+_\${1}
IFS=\$'\n'
echo "\${COMPREPLY[*]}" | sort | uniq
EOF
-complete git 'p/*/`bash ${__git_tcsh_completion_script}
"${COMMAND_LINE}"`/'
-complete gitk 'p/*/`bash ${__git_tcsh_completion_script}
"${COMMAND_LINE}"`/'
+complete git 'p/*/`bash ${__git_tcsh_completion_script} git
"${COMMAND_LINE}"`/'
+complete gitk 'p/*/`bash ${__git_tcsh_completion_script} gitk
"${COMMAND_LINE}"`/'
--
1.8.0.1.g9fe2839
^ permalink raw reply related
* Re: [PATCH 5/7] push: require force for refs under refs/tags/
From: Chris Rorvick @ 2012-11-27 4:17 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Angelo Borsotti, Drew Northup, Michael Haggerty,
Philip Oakley, Johannes Sixt, Kacper Kornet, Jeff King,
Felipe Contreras
In-Reply-To: <7vfw3wry4d.fsf@alter.siamese.dyndns.org>
On Mon, Nov 26, 2012 at 12:57 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Chris Rorvick <chris@rorvick.com> writes:
>
>> diff --git a/remote.c b/remote.c
>> index 4a6f822..012b52f 100644
>> --- a/remote.c
>> +++ b/remote.c
>> @@ -1315,14 +1315,18 @@ void set_ref_status_for_push(struct ref *remote_refs, int send_mirror,
>> *
>> * (1) if the old thing does not exist, it is OK.
>> *
>> - * (2) if you do not have the old thing, you are not allowed
>> + * (2) if the destination is under refs/tags/ you are
>> + * not allowed to overwrite it; tags are expected
>> + * to be static once created
>> + *
>> + * (3) if you do not have the old thing, you are not allowed
>> * to overwrite it; you would not know what you are losing
>> * otherwise.
>> *
>> - * (3) if both new and old are commit-ish, and new is a
>> + * (4) if both new and old are commit-ish, and new is a
>> * descendant of old, it is OK.
>> *
>> - * (4) regardless of all of the above, removing :B is
>> + * (5) regardless of all of the above, removing :B is
>> * always allowed.
>> */
>
> We may want to reword (0) to make it clear that --force
> (and +A:B) can be used to defeat all the other rules.
On that note, having (5) be "regardless of all of the above ..." seems
a little awkward. That would seem to fit better towards the top.
^ permalink raw reply
* Re: Interesting git-format-patch bug
From: Perry Hutchison @ 2012-11-27 4:15 UTC (permalink / raw)
To: gitster; +Cc: git, alan.r.olsen
In-Reply-To: <7vobikotwd.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> "Olsen, Alan R" <alan.r.olsen@intel.com> writes:
> > I found an interesting bug in git-format-patch.
> >
> > Say you have a branch A. You create branch B and add a patch to
> > it. You then merge that patch into branch A. After the merge,
> > some other process (we will call it 'gerrit') uses annotate and
> > changes the comment on the patch that exists on branch B.
> >
> > Now someone runs git-format-patch for the last n patches on
> > branch A. You should just get the original patch that was
> > merged over to branch A. What you get is the patch that was
> > merged to branch A *and* the patch with the modified commit
> > comment on branch B. (Double the patches, double the
> > clean-up...)
>
> As you literally have patches that do essentially the same or
> similar things on two branches that was merged, you cannot
> expect to export each individual commit into a patch and not
> have conflicts among them. So I do not think there is no
> answer than "don't do that".
To me, this seems to miss Alan's point: only one patch was merged
to branch A, so git-format-patch applied to branch A should find
only one patch. It can be argued either way whether that one-patch
report should include the gerrit annotations, but surely the
application of gerrit on branch B, _after the merge to branch A
has already been performed_, should not cause an additional patch
to magically appear on branch A.
^ permalink raw reply
* Re: difftool -d symlinks, under what conditions
From: David Aguilar @ 2012-11-27 6:20 UTC (permalink / raw)
To: Matt McClure; +Cc: git, Tim Henigan
In-Reply-To: <CAJELnLGq_oLBiNHANoaE7iEiA6g4fXX0PtJbqPFi4PQ+5LLvnA@mail.gmail.com>
On Mon, Nov 26, 2012 at 12:23 PM, Matt McClure
<matthewlmcclure@gmail.com> wrote:
> I'm finding the behavior of `git difftool -d` surprising. It seems that it
> only uses symlinks to the working copy for files that are modified in the
> working copy since the most recent commit. I would have expected it to use
> symlinks for all files whose version under comparison is the working copy
> version, regardless of whether the working copy differs from the HEAD.
>
> I'm using
>
> $ git --version
> git version 1.8.0
>
> on a Mac from Homebrew.
cc:ing Tim since he probably remembers this feature.
This is a side-effect of how it's currently implemented,
and the general-purpose nature of the "diff" command.
diff can also be used for diffing arbitrary commits.
The simplest way to implement that is to create two temporary
directories containing "a/" and "b/" and then launch the tool
against them. That's what difftool does; it creates a temporary
index and uses `git checkout-index` to populate these two dirs.
The worktree handling is a bolt-on that symlinks
(or copies (on windows or with --no-symlinks)) modified
worktree files into one of these temporary directories.
When symlinks are used (the default) we avoid needing to
copy these files back into the worktree; we can blindly
remove the temporary directories without checking whether
the tool edited any files.
When copies are used we check their content for changes
before deciding to copy them back into the worktree.
Files that are not modified are not considered part of the
set of files to check when copying back, or when symlinking,
mostly because that's just how it's implemented right now.
It seems that there is an edge case here that we are not
accounting for: unmodified worktree paths, when checked out
into the temporary directory, can be edited by the tool when
comparing against older commits. These edits will be lost.
If we had a way to know that either a/ or b/ can be replaced
with the worktree itself then we could make it even simpler.
Right now we don't because difftool barely parses the
command-line at all; most of it is parsed by git-diff.
Originally, difftool was a read-only tool so it was able to
avoid needing to know too much about what diff is really doing.
We would need to a way to re-use git's diff command-line parsing
logic to answer: "is the worktree involved in this diff invocation?"
When we can do that then we avoid needing to have a temporary
directory altogether for any dir-diffs that involve the worktree.
Does anyone know of a good way to answer that question?
The input is the command-line provided to diff/difftool.
The output is one of ('a', 'b', 'x'), where 'a' means the left
side of the diff is the worktree, 'b' means the right side,
and 'x' means neither (e.g. the command-line contains two refs).
Assuming we can do this, it would also make dir-diff faster
since we can avoid needing to checkout the entire tree for
that side of the diff.
--
David
^ permalink raw reply
* Re: gitpacker progress report and a question
From: Felipe Contreras @ 2012-11-27 6:29 UTC (permalink / raw)
To: esr; +Cc: git
In-Reply-To: <20121126234359.GA8042@thyrsus.com>
On Tue, Nov 27, 2012 at 12:43 AM, Eric S. Raymond <esr@thyrsus.com> wrote:
> -----------------------------------
> commit 1
> directory foo-1.1
>
> Release 1.1 of project foo
> .
> commit 2
> directory foo-1.2
>
> ..This is an example of a byte-stuffed line.
>
> Release 1.2 of project foo
> .
> commit 3
> directory foo-1.3
>
> Release 1.3 of project foo
> .
> -----------------------------------
>
> The main objective of the logfile design is to make hand-crafting
> these easy.
Here's another version with YAML:
---
-
author: &me Felipe Contreras <felipe.contreras@gmail.com>
date: 2011-1-1
msg: one
- tag v0.1
-
author: *me
date: 2011-1-2
msg: extra
-
author: *me
date: 2011-1-3
msg: |
with
spaces
-
author: *me
date: 2011-1-4
msg: |
dot
.
-
author: *me
date: 2011-1-5
msg: remove
ref: remove
- checkout devel
-
author: *me
date: 2011-1-6
msg: dev
- checkout master
-
author: *me
date: 2011-1-7
msg: bump
- tag v0.2
- checkout test remove
---
I believe that log file is much more human readable. Yet I still fail
to see why would anybody want so much detail only to import tarballs.
diff --git a/contrib/weave/git-weave b/contrib/weave/git-weave
new file mode 100755
index 0000000..646aeaa
--- /dev/null
+++ b/contrib/weave/git-weave
@@ -0,0 +1,234 @@
+#!/usr/bin/env ruby
+
+require 'optparse'
+require 'find'
+require 'fileutils'
+require 'yaml'
+
+$last = nil
+$branches = {}
+$branch = 'master'
+$refs = {}
+
+class Commit
+
+ attr_reader :id, :parents, :author, :committer, :date, :msg, :ref
+
+ @@num = 0
+
+ def initialize(args)
+ @id = @@num += 1
+ @parents = []
+ args.each do |key, value|
+ instance_variable_set("@#{key}", value)
+ end
+ if @author =~ /(.+ <.+>) (.+)/
+ @author = $1
+ end
+ if @committer =~ /(.+ <.+>) (.+)/
+ @committer = $1
+ @date = DateTime.strptime($2, '%s %z')
+ end
+ $refs[@ref] = @id if @ref
+ end
+
+end
+
+def export_commit(cmd, indir, out)
+
+ c = Commit.new(cmd)
+ $last = c.id
+
+ # commit
+ out.puts 'commit refs/heads/%s' % $branch
+ out.puts 'mark :%u' % c.id
+ if c.author and c.committer
+ out.puts 'author %s %s' % [c.author, c.date.strftime('%s %z')]
+ out.puts 'committer %s %s' % [c.committer, c.date.strftime('%s %z')]
+ else
+ out.puts 'committer %s %s' % [c.author, c.date.strftime('%s %z')]
+ end
+ out.puts 'data %u' % c.msg.bytesize
+ out.puts c.msg
+
+ # parents
+ c.parents.each_with_index do |p, i|
+ ref = $refs[p]
+ if i == 0
+ out.puts 'from :%u' % ref
+ else
+ out.puts 'merge :%u' % ref
+ end
+ end
+
+ # files
+ out.puts 'deleteall'
+ FileUtils.cd(File.join(indir, c.id.to_s)) do
+ Find.find('.') do |e|
+ next unless File.file?(e)
+ content = File.read(e)
+ filename = e.split(File::SEPARATOR).slice(1..-1).join(File::SEPARATOR)
+ if File.symlink?(e)
+ mode = '120000'
+ content = File.readlink(e)
+ else
+ mode = File.executable?(e) ? '100755' : '100644'
+ end
+ out.puts 'M %s inline %s' % [mode, filename]
+ out.puts 'data %u' % content.bytesize
+ out.puts content
+ end
+ end
+ out.puts
+
+end
+
+def do_reset(out, ref, from)
+ out.puts "reset %s" % ref
+ out.puts "from :%u" % from
+ out.puts
+end
+
+def export_reset(cmd, indir, out)
+ _, ref, from = cmd.split
+ do_reset(out, ref, from)
+end
+
+def export_checkout(cmd, indir, out)
+ _, $branch, from = cmd.split
+ from = ':%u' % $last if not $branches[$branch]
+ do_reset(out, 'refs/heads/%s' % $branch, from) if from
+ $branches[$branch] = true
+end
+
+def export_tag(cmd, indir, out)
+ _, tag = cmd.split
+ do_reset(out, 'refs/tags/%s' % tag, $last)
+end
+
+def export(indir = '.', out = STDOUT)
+
+ $branches['master'] = true
+
+ YAML.load_file(File.join(indir, 'log')).each do |e|
+ case e
+ when Hash
+ export_commit(e, indir, out)
+ when /^checkout /
+ export_checkout(e, indir, out)
+ when /^tag /
+ export_tag(e, indir, out)
+ when /^reset /
+ export_reset(e, indir, out)
+ end
+ end
+
+end
+
+def import(outdir, out)
+ format = 'format:commit %H%nauthor %an <%ae> %ad%ncommitter %cn
<%ce> %cd%nparents %P%n%n%B'
+ cmd = ['git', 'log', '-z', '-s', '--date=raw', '--format=%s' %
format, '--reverse', '--all']
+ commits = {}
+
+ cmds = []
+
+ IO.popen(cmd).each_with_index("\0") do |data, i|
+ @msg = nil
+ @parents = []
+ data.chomp("\0").each_line do |l|
+ if not @msg
+ case l
+ when /^commit (.+)$/
+ @id = $1
+ when /^author (.+)$/
+ @author = $1
+ when /^committer (.+)$/
+ @committer = $1
+ when /^parents (.+)$/
+ @parents = $1.split(" ")
+ when /^$/
+ @msg = ""
+ end
+ else
+ @msg << l
+ end
+ end
+
+ num = i + 1
+ commits[@id] = num
+
+ cmds << {
+ :author => @author,
+ :committer => @committer,
+ :msg => @msg,
+ :ref => num,
+ :parents => @parents.map { |e| commits[e] },
+ }
+
+ wd = File.join(outdir, num.to_s)
+ FileUtils.mkdir_p(wd)
+ system('git', '--work-tree', wd, 'checkout', '-f', '-q', @id)
+ end
+
+ IO.popen(['git', 'show-ref', '--tags', '--heads']).each do |e|
+ id, ref = e.chomp.split
+ cmds << 'reset %s %s' % [ref, commits[id]]
+ end
+
+ out.write(cmds.to_yaml)
+end
+
+def git_pack(indir, outdir)
+ indir = File.absolute_path(indir)
+ system('git', 'init', '--quiet', outdir)
+ FileUtils.cd(outdir) do
+ IO.popen(['git', 'fast-import', '--quiet'], 'w') do |io|
+ export(indir, io)
+ end
+ system('git', 'reset', '--quiet', '--hard')
+ end
+end
+
+def git_unpack(indir, outdir)
+ begin
+ FileUtils.mkdir_p(outdir)
+ log = File.open(File.join(outdir, 'log'), 'w')
+ ENV['GIT_DIR'] = File.join(indir, '.git')
+ oldref = %x[git symbolic-ref HEAD]
+ import(outdir, log)
+ ensure
+ system('git', 'symbolic-ref', 'HEAD', oldref) if oldref
+ ENV.delete('GIT_DIR')
+ log.close if log
+ end
+end
+
+$indir = '.'
+
+begin
+ OptionParser.new do |opts|
+ opts.on('-x') do
+ $mode = 'unpack'
+ end
+ opts.on('-c') do
+ $mode = 'pack'
+ end
+ opts.on('-o', '--outdir DIR') do |v|
+ $outdir = v
+ end
+ opts.on('-i', '--indir DIR') do |v|
+ $indir = v
+ end
+ end.parse!
+rescue OptionParser::InvalidOption
+end
+
+$mode = File.exists?(File.join($indir, '.git')) ? 'unpack' : 'pack'
unless $mode
+$outdir = File.join($indir, $mode == 'pack' ? 'packed' : 'unpacked2')
unless $outdir
+
+case $mode
+when 'pack'
+ git_pack($indir, $outdir)
+when 'unpack'
+ git_unpack($indir, $outdir)
+end
--
Felipe Contreras
^ permalink raw reply related
* Re: gitpacker progress report and a question
From: Eric S. Raymond @ 2012-11-27 7:27 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <CAMP44s3=VpMv-S2eV9rXRaH9U3SvaR8B6Dto=vAmVQ_XB1uBXg@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com>:
> I believe that log file is much more human readable. Yet I still fail
> to see why would anybody want so much detail only to import tarballs.
The first time I needed such a tool (and I really should have built it then)
was during the events I wrote up in 2010 the INTERCAL Reconstruction Massacree;
full story at <http://esr.ibiblio.org/?p=2491> Note in particular the
following paragraphs:
Reconstructing the history of C-INTERCAL turned out to be something of
an epic in itself. 1990 was back in the Dark Ages as far as version
control and release-management practices go; our tools were
paleolithic and our procedures likewise. The earliest versions of
C-INTERCAL were so old that even CVS wasn’t generally available yet
(CVS 1.0 didn’t even ship until six months after C-INTERCAL 0.3, my
first public release). SCCS had existed since the early 1980s but was
proprietary; the only game in town was RCS. Primitive, file-oriented
RCS.
I was a very early adopter of version control; when I wrote
Emacs’s VC mode in 1992 the idea of integrating version control
into normal workflow that closely was way out in front of current
practice. Today’s routine use of such tools wasn’t even a gleam in
anyone’s eye then, if only because disks were orders of magnitude
smaller and there was a lot of implied pressure to actually throw
away old versions of stuff. So I only RCSed some of the files in
the project at the time, and didn’t think much about that.
As a result, reconstructing C-INTERCAL’s history turned into about two
weeks of work. A good deal of it was painstaking digital archeology,
digging into obscure corners of the net for ancient release tarballs
Alex and I didn’t have on hand any more. I ended up stitching together
material from 18 different release tarballs, 11 unreleased snapshot
tarballs, one release tarball I could reconstruct, one release tarball
mined out of an obsolete Red Hat source RPM, two shar archives, a pax
archive, five published patches, two zip files, a darcs archive, and
my partial RCS history, and that’s before we got to the aerial
photography. To perform the surgery needed to integrate this, I wrote
a custom Python program assisted by two shellscripts, topping out at a
hair over 1200 lines of code.
The second time was much more recent and concerned a project called
(seriously) robotfindskitten. This code existed as a partial CVS
repository created by someone other than the original author,
and some disconnected tarballs from before the repo. The author
has requested that I knit the tarballs and the CVS history (which
is now in git) into one repository.
In both cases the object was to assemble a coherent history
from all the available metadata as if the projects had been using
version control all along.
I know of at least one other group of disconnected tarballs, of a
program called xlife, that is likely to need similar treatment. It's
not an uncommon situation for projects over a certain age, and there is
lots of code like xlife dating from before the mid-1990s waiting for
someone to pick up the pieces.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* Re: gitpacker progress report and a question
From: Eric S. Raymond @ 2012-11-27 7:30 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <CAMP44s3=VpMv-S2eV9rXRaH9U3SvaR8B6Dto=vAmVQ_XB1uBXg@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com>:
> > The main objective of the logfile design is to make hand-crafting
> > these easy.
>
> Here's another version with YAML:
Clever.
Now I have to decide if I should allow my aesthetic dislike of YAML to
prevail despite the fact that it's pretty well suited to this job. There
is definitely a case for applying a standard metaprotocol like YAML (ugh)
or XML (double ugh).
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* Re: Python extension commands in git - request for policy change
From: David Aguilar @ 2012-11-27 7:54 UTC (permalink / raw)
To: Felipe Contreras; +Cc: esr, Nguyen Thai Ngoc Duy, git, msysGit
In-Reply-To: <CAMP44s2FcrjDhNzond=Rzmn5QOBnZbQC1d73ZmKNeyCRvJNvyA@mail.gmail.com>
On Mon, Nov 26, 2012 at 5:11 AM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> And I don't agree that the project would be better off with something
> else, if it was, somebody would have proposed an alternative by now,
> but there aren't any. I have tried gitg, and giggle, and I have even
> contributed to them, but they are just not as good and useful as plain
> old gitk, I always keep coming back.
>
> gitk:
> * is blazing fast to start
> * doesn't have a lot of dependencies: just tcl/tk
> * works on Windows without a major fuzz
> * is actively maintained
> * shows a proper graph (unlike gitg or giggle)
>
> Now, show me an alternative that fulfills all these points. And I'm
> pretty sure you won't find one, because if you did, it would have been
> already proposed for mainline git... there isn't any. And if you did,
> we would start with oh, but it's GTK+, or it's Qt, and how do you make
> it work on Windows. No, gitk is just fine, and works great.
>
> Tcl/Tk might not be your cup of tea, and indeed it's rather unmodern,
> but that only tells you how an awful job the modern toolkits have done
> with regards to portability and flexibility.
>
> You were arguing for portability, well, Tcl/Tk works on all platforms,
> here, have a look, there's no other tool that fulfills this:
>
> http://www.mediawiki.org/wiki/Git/Graphical_User_Interfaces
*cough* git-cola *cough*
it runs everywhere. Yes, windows too. It's written in python.
It's been actively maintained since 2007.
It's "modern" and has features that don't exist anywhere else.
It even has tests. It even comes with a building full of willing
guinea-pigs^Wtesters that let me know right away when
anything goes wrong.
It uses Qt but that's really the whole point of Qt -> cross-platform.
(not sure how that wiki page ended up saying Gnome/GTK?)
The DAG aka git-dag (in its master branch, about to be released)
is nicer looking then gitk IMO. gitk still has some features
that are better too--there's no silver bullet, but the delta
is pretty small.
The only point this doesn't fulfill is dependency-free-ness.
With that requirement the answer can *only* be tcl/tk.
So saying, "go look for one you won't find it" is really
a tautology. It's not even an entertaining one.
http://xkcd.com/703/
When the requirement is, "what is the best user experience
possible", then you use a mature GUI library. These are different
requirements and probably different use cases. For the gitk use
case, gitk is the perfect tool.
Anyways, just sayin', you make it sound like this stuff doesn't
exist, but it does. I've never proposed it for mainline
git because I'm very aware of the dependency requirements.
But, if git "recommended" it I would very much appreciate the
extra eyes and contributions. Being in mainline git could
possibly help with that. A submodule under contrib/
would be an interesting experiment.
In any case, I think documenting the python standards
(even if within contrib/ only) is a good thing.
We'd be increasing the overall portability by documenting
what we support and sticking to it, just
like what is done for shell scripts and perl versions.
Eric is helping make that happen, let's not throw
out the baby with the bathwater. FWIW, I would also make
my python expertise available.
This thread has gotten into meta-meta territory --
it's discussing code that has not yet even been written,
and going off on all sorts of tangents.
Let's stay on target. I think bringing up python
as an extension language would help in a these key areas:
- There are a few python modules floating around that
are similar to the ruby grit library. Having an official
python module would be good.
- Commands on the edges of the git experience (GUIs,
import/export/etc) can benefit from python. git-p4
is one example. git-weave is another.
Are there any arguments against it for these use cases?
BTW, Felipe, if you're going to be rewriting python code to ruby,
please, pretty please rewrite that darn GUI ;-)
You can call it "git-new-cola: project kansas"
http://en.wikipedia.org/wiki/New_Coke
I expect a patch by the morning ;-p
I kid, of course, but if you do pull it off I WILL buy you a soda-pop!
--
David
^ permalink raw reply
* Re: gitpacker progress report and a question
From: Felipe Contreras @ 2012-11-27 8:20 UTC (permalink / raw)
To: esr; +Cc: git
In-Reply-To: <20121127072700.GA23169@thyrsus.com>
On Tue, Nov 27, 2012 at 8:27 AM, Eric S. Raymond <esr@thyrsus.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com>:
>> I believe that log file is much more human readable. Yet I still fail
>> to see why would anybody want so much detail only to import tarballs.
> In both cases the object was to assemble a coherent history
> from all the available metadata as if the projects had been using
> version control all along.
I didn't say I couldn't see why somebody would need such a tool, I
said I couldn't see why somebody would need such a tool _with so much
detail_.
Most of those old projects have a linear history, so a log file like
this would suffice:
tag v0.1 gst-av-0.1.tar "Release 0.1"
tag v0.2 gst-av-0.2.tar "Release 0.2"
tag v0.3 gst-av-0.3.tar "Release 0.3"
And if they really had release branches, it shouldn't be difficult to
modify it for:
tag v0.1 gst-av-0.1.tar "Release 0.1"
tag v0.2 gst-av-0.2.tar "Release 0.2"
tag v0.2.1 gst-av-0.2.tar "Release 0.2.1"
checkout v0.2
tag v0.3 gst-av-0.3.tar "Release 0.3"
But different commit/author and respective dates, and merges? Sounds
like overkill.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: gitpacker progress report and a question
From: Eric S. Raymond @ 2012-11-27 8:36 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <CAMP44s1=sjWypEN3zzC=aPqZYnBFU0C+Dhrh3zj=jY57PHJ6wg@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com>:
> Most of those old projects have a linear history,
INTERCAL didn't. There were two branches for platform ports.
> But different commit/author and respective dates, and merges? Sounds
> like overkill.
I felt it was important that the metadata format be able to specify
git's entire metadata and DAG semantics. Otherwise, as sure as the
sun rises, *somebody* would run into a corner case not covered, and
(quite rightly) curse me for a shortsighted fool who had done a
half-assed job.
I don't do half-assed jobs. Not ever, no way, nohow.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* [PATCH 0/4] t4041 (diff-submodule-option): minor cleanup
From: Ramkumar Ramachandra @ 2012-11-27 8:41 UTC (permalink / raw)
To: Git List
Hi,
This is the result of one lazy afternoon.
Ram
Ramkumar Ramachandra (4):
t4041 (diff-submodule-option): parse digests sensibly
t4041 (diff-submodule-option): rewrite add_file() routine
t4041 (diff-submodule-option): modernize style
t4041 (diff-submodule-option): change tense of test names
t/t4041-diff-submodule-option.sh | 484 +++++++++++++++++++-------------------
1 files changed, 240 insertions(+), 244 deletions(-)
--
1.7.8.1.362.g5d6df.dirty
^ permalink raw reply
* [PATCH 1/4] t4041 (diff-submodule-option): parse digests sensibly
From: Ramkumar Ramachandra @ 2012-11-27 8:41 UTC (permalink / raw)
To: Git List
In-Reply-To: <1354005692-2809-1-git-send-email-artagnon@gmail.com>
`git rev-list --max-count=1 HEAD` is a roundabout way of saying `git
rev-parse --verify HEAD`; replace a bunch of instances of the former
with the latter. Also, don't unnecessarily `cut -c1-7` the rev-parse
output when the `--short` option is available.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
---
t/t4041-diff-submodule-option.sh | 14 +++++++-------
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/t/t4041-diff-submodule-option.sh b/t/t4041-diff-submodule-option.sh
index 5377639..cfb71e5 100755
--- a/t/t4041-diff-submodule-option.sh
+++ b/t/t4041-diff-submodule-option.sh
@@ -21,7 +21,7 @@ add_file () {
test_tick &&
git commit -m "Add $name"
done >/dev/null
- git rev-parse --verify HEAD | cut -c1-7
+ git rev-parse --short --verify HEAD
cd "$owd"
}
commit_file () {
@@ -33,7 +33,7 @@ test_create_repo sm1 &&
add_file . foo >/dev/null
head1=$(add_file sm1 foo1 foo2)
-fullhead1=$(cd sm1; git rev-list --max-count=1 $head1)
+fullhead1=$(cd sm1; git rev-parse --verify $head1)
test_expect_success 'added submodule' "
git add sm1 &&
@@ -116,8 +116,8 @@ EOF
test_cmp expected actual
"
-fullhead2=$(cd sm1; git rev-list --max-count=1 $head2)
test_expect_success 'modified submodule(forward) --submodule=short' "
+fullhead2=$(cd sm1; git rev-parse --verify $head2)
git diff --submodule=short >actual &&
cat >expected <<-EOF &&
diff --git a/sm1 b/sm1
@@ -135,7 +135,7 @@ commit_file sm1 &&
head3=$(
cd sm1 &&
git reset --hard HEAD~2 >/dev/null &&
- git rev-parse --verify HEAD | cut -c1-7
+ git rev-parse --short --verify HEAD
)
test_expect_success 'modified submodule(backward)' "
@@ -220,8 +220,8 @@ EOF
rm -f sm1 &&
test_create_repo sm1 &&
head6=$(add_file sm1 foo6 foo7)
-fullhead6=$(cd sm1; git rev-list --max-count=1 $head6)
test_expect_success 'nonexistent commit' "
+fullhead6=$(cd sm1; git rev-parse --verify $head6)
git diff-index -p --submodule=log HEAD >actual &&
cat >expected <<-EOF &&
Submodule sm1 $head4...$head6 (commits not present)
@@ -318,8 +318,8 @@ EOF
"
(cd sm1; git commit -mchange foo6 >/dev/null) &&
-head8=$(cd sm1; git rev-parse --verify HEAD | cut -c1-7) &&
test_expect_success 'submodule is modified' "
+head8=$(cd sm1; git rev-parse --short --verify HEAD) &&
git diff-index -p --submodule=log HEAD >actual &&
cat >expected <<-EOF &&
Submodule sm1 $head6..$head8:
@@ -461,7 +461,7 @@ EOF
test_cmp expected actual
"
-fullhead7=$(cd sm2; git rev-list --max-count=1 $head7)
+fullhead7=$(cd sm2; git rev-parse --verify $head7)
test_expect_success 'given commit --submodule=short' "
git diff-index -p --submodule=short HEAD^ >actual &&
--
1.7.8.1.362.g5d6df.dirty
^ permalink raw reply related
* [PATCH 2/4] t4041 (diff-submodule-option): rewrite add_file() routine
From: Ramkumar Ramachandra @ 2012-11-27 8:41 UTC (permalink / raw)
To: Git List
In-Reply-To: <1354005692-2809-1-git-send-email-artagnon@gmail.com>
Instead of "cd there and then come back", use the "cd there in a
subshell" pattern. Also fix '&&' chaining in one place.
Suggested-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
---
t/t4041-diff-submodule-option.sh | 13 +++++--------
1 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/t/t4041-diff-submodule-option.sh b/t/t4041-diff-submodule-option.sh
index cfb71e5..103c690 100755
--- a/t/t4041-diff-submodule-option.sh
+++ b/t/t4041-diff-submodule-option.sh
@@ -11,18 +11,15 @@ This test tries to verify the sanity of the --submodule option of git diff.
. ./test-lib.sh
add_file () {
- sm=$1
- shift
- owd=$(pwd)
- cd "$sm"
- for name; do
+ (cd "$1" &&
+ shift &&
+ for name; do
echo "$name" > "$name" &&
git add "$name" &&
test_tick &&
git commit -m "Add $name"
- done >/dev/null
- git rev-parse --short --verify HEAD
- cd "$owd"
+ done >/dev/null &&
+ git rev-parse --short --verify HEAD)
}
commit_file () {
test_tick &&
--
1.7.8.1.362.g5d6df.dirty
^ permalink raw reply related
* [PATCH 4/4] t4041 (diff-submodule-option): change tense of test names
From: Ramkumar Ramachandra @ 2012-11-27 8:41 UTC (permalink / raw)
To: Git List
In-Reply-To: <1354005692-2809-1-git-send-email-artagnon@gmail.com>
Change the tense of test names from past to present, as this is the
prevalent style.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
---
t/t4041-diff-submodule-option.sh | 24 ++++++++++++------------
1 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/t/t4041-diff-submodule-option.sh b/t/t4041-diff-submodule-option.sh
index f61c664..25cefba 100755
--- a/t/t4041-diff-submodule-option.sh
+++ b/t/t4041-diff-submodule-option.sh
@@ -32,7 +32,7 @@ add_file . foo >/dev/null
head1=$(add_file sm1 foo1 foo2)
fullhead1=$(cd sm1; git rev-parse --verify $head1)
-test_expect_success 'added submodule' '
+test_expect_success 'add submodule' '
git add sm1 &&
git diff-index -p --submodule=log HEAD >actual &&
cat >expected <<-EOF &&
@@ -41,7 +41,7 @@ test_expect_success 'added submodule' '
test_cmp expected actual
'
-test_expect_success 'added submodule, set diff.submodule' '
+test_expect_success 'add submodule, set diff.submodule' '
git config diff.submodule log &&
git add sm1 &&
git diff --cached >actual &&
@@ -86,7 +86,7 @@ test_expect_success 'diff.submodule does not affect plumbing' '
commit_file sm1 &&
head2=$(add_file sm1 foo3)
-test_expect_success 'modified submodule(forward)' '
+test_expect_success 'modify submodule(forward)' '
git diff-index -p --submodule=log HEAD >actual &&
cat >expected <<-EOF &&
Submodule sm1 $head1..$head2:
@@ -95,7 +95,7 @@ test_expect_success 'modified submodule(forward)' '
test_cmp expected actual
'
-test_expect_success 'modified submodule(forward)' '
+test_expect_success 'modify submodule(forward)' '
git diff --submodule=log >actual &&
cat >expected <<-EOF &&
Submodule sm1 $head1..$head2:
@@ -104,7 +104,7 @@ test_expect_success 'modified submodule(forward)' '
test_cmp expected actual
'
-test_expect_success 'modified submodule(forward) --submodule' '
+test_expect_success 'modify submodule(forward) --submodule' '
git diff --submodule >actual &&
cat >expected <<-EOF &&
Submodule sm1 $head1..$head2:
@@ -114,7 +114,7 @@ test_expect_success 'modified submodule(forward) --submodule' '
'
fullhead2=$(cd sm1; git rev-parse --verify $head2)
-test_expect_success 'modified submodule(forward) --submodule=short' '
+test_expect_success 'modify submodule(forward) --submodule=short' '
git diff --submodule=short >actual &&
cat >expected <<-EOF &&
diff --git a/sm1 b/sm1
@@ -135,7 +135,7 @@ head3=$(
git rev-parse --short --verify HEAD
)
-test_expect_success 'modified submodule(backward)' '
+test_expect_success 'modify submodule(backward)' '
git diff-index -p --submodule=log HEAD >actual &&
cat >expected <<-EOF &&
Submodule sm1 $head2..$head3 (rewind):
@@ -146,7 +146,7 @@ test_expect_success 'modified submodule(backward)' '
'
head4=$(add_file sm1 foo4 foo5)
-test_expect_success 'modified submodule(backward and forward)' '
+test_expect_success 'modify submodule(backward and forward)' '
git diff-index -p --submodule=log HEAD >actual &&
cat >expected <<-EOF &&
Submodule sm1 $head2...$head4:
@@ -166,7 +166,7 @@ git add sm1 &&
rm -f sm1 &&
mv sm1-bak sm1
-test_expect_success 'typechanged submodule(submodule->blob), --cached' '
+test_expect_success 'typechange submodule(submodule->blob), --cached' '
git diff --submodule=log --cached >actual &&
cat >expected <<-EOF &&
Submodule sm1 $head4...0000000 (submodule deleted)
@@ -181,7 +181,7 @@ test_expect_success 'typechanged submodule(submodule->blob), --cached' '
test_cmp expected actual
'
-test_expect_success 'typechanged submodule(submodule->blob)' '
+test_expect_success 'typechange submodule(submodule->blob)' '
git diff --submodule=log >actual &&
cat >expected <<-EOF &&
diff --git a/sm1 b/sm1
@@ -198,7 +198,7 @@ test_expect_success 'typechanged submodule(submodule->blob)' '
rm -rf sm1 &&
git checkout-index sm1
-test_expect_success 'typechanged submodule(submodule->blob)' '
+test_expect_success 'typechange submodule(submodule->blob)' '
git diff-index -p --submodule=log HEAD >actual &&
cat >expected <<-EOF &&
Submodule sm1 $head4...0000000 (submodule deleted)
@@ -226,7 +226,7 @@ test_expect_success 'nonexistent commit' '
'
commit_file
-test_expect_success 'typechanged submodule(blob->submodule)' '
+test_expect_success 'typechange submodule(blob->submodule)' '
git diff-index -p --submodule=log HEAD >actual &&
cat >expected <<-EOF &&
diff --git a/sm1 b/sm1
--
1.7.8.1.362.g5d6df.dirty
^ permalink raw reply related
* [PATCH 3/4] t4041 (diff-submodule-option): modernize style
From: Ramkumar Ramachandra @ 2012-11-27 8:41 UTC (permalink / raw)
To: Git List
In-Reply-To: <1354005692-2809-1-git-send-email-artagnon@gmail.com>
- Enclose tests in single quotes as opposed to double quotes. This is
the prevalent style in other tests.
- Remove the unused variable $head4_full.
- Indent the expected output so that it lines up with the rest of the
test text.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
---
t/t4041-diff-submodule-option.sh | 459 +++++++++++++++++++-------------------
1 files changed, 229 insertions(+), 230 deletions(-)
diff --git a/t/t4041-diff-submodule-option.sh b/t/t4041-diff-submodule-option.sh
index 103c690..f61c664 100755
--- a/t/t4041-diff-submodule-option.sh
+++ b/t/t4041-diff-submodule-option.sh
@@ -32,41 +32,41 @@ add_file . foo >/dev/null
head1=$(add_file sm1 foo1 foo2)
fullhead1=$(cd sm1; git rev-parse --verify $head1)
-test_expect_success 'added submodule' "
+test_expect_success 'added submodule' '
git add sm1 &&
git diff-index -p --submodule=log HEAD >actual &&
cat >expected <<-EOF &&
-Submodule sm1 0000000...$head1 (new submodule)
-EOF
+ Submodule sm1 0000000...$head1 (new submodule)
+ EOF
test_cmp expected actual
-"
+'
-test_expect_success 'added submodule, set diff.submodule' "
+test_expect_success 'added submodule, set diff.submodule' '
git config diff.submodule log &&
git add sm1 &&
git diff --cached >actual &&
cat >expected <<-EOF &&
-Submodule sm1 0000000...$head1 (new submodule)
-EOF
+ Submodule sm1 0000000...$head1 (new submodule)
+ EOF
git config --unset diff.submodule &&
test_cmp expected actual
-"
+'
-test_expect_success '--submodule=short overrides diff.submodule' "
+test_expect_success '--submodule=short overrides diff.submodule' '
test_config diff.submodule log &&
git add sm1 &&
git diff --submodule=short --cached >actual &&
cat >expected <<-EOF &&
-diff --git a/sm1 b/sm1
-new file mode 160000
-index 0000000..$head1
---- /dev/null
-+++ b/sm1
-@@ -0,0 +1 @@
-+Subproject commit $fullhead1
-EOF
+ diff --git a/sm1 b/sm1
+ new file mode 160000
+ index 0000000..$head1
+ --- /dev/null
+ +++ b/sm1
+ @@ -0,0 +1 @@
+ +Subproject commit $fullhead1
+ EOF
test_cmp expected actual
-"
+'
test_expect_success 'diff.submodule does not affect plumbing' '
test_config diff.submodule log &&
@@ -86,47 +86,47 @@ test_expect_success 'diff.submodule does not affect plumbing' '
commit_file sm1 &&
head2=$(add_file sm1 foo3)
-test_expect_success 'modified submodule(forward)' "
+test_expect_success 'modified submodule(forward)' '
git diff-index -p --submodule=log HEAD >actual &&
cat >expected <<-EOF &&
-Submodule sm1 $head1..$head2:
- > Add foo3
-EOF
+ Submodule sm1 $head1..$head2:
+ > Add foo3
+ EOF
test_cmp expected actual
-"
+'
-test_expect_success 'modified submodule(forward)' "
+test_expect_success 'modified submodule(forward)' '
git diff --submodule=log >actual &&
cat >expected <<-EOF &&
-Submodule sm1 $head1..$head2:
- > Add foo3
-EOF
+ Submodule sm1 $head1..$head2:
+ > Add foo3
+ EOF
test_cmp expected actual
-"
+'
-test_expect_success 'modified submodule(forward) --submodule' "
+test_expect_success 'modified submodule(forward) --submodule' '
git diff --submodule >actual &&
cat >expected <<-EOF &&
-Submodule sm1 $head1..$head2:
- > Add foo3
-EOF
+ Submodule sm1 $head1..$head2:
+ > Add foo3
+ EOF
test_cmp expected actual
-"
+'
-test_expect_success 'modified submodule(forward) --submodule=short' "
fullhead2=$(cd sm1; git rev-parse --verify $head2)
+test_expect_success 'modified submodule(forward) --submodule=short' '
git diff --submodule=short >actual &&
cat >expected <<-EOF &&
-diff --git a/sm1 b/sm1
-index $head1..$head2 160000
---- a/sm1
-+++ b/sm1
-@@ -1 +1 @@
--Subproject commit $fullhead1
-+Subproject commit $fullhead2
-EOF
+ diff --git a/sm1 b/sm1
+ index $head1..$head2 160000
+ --- a/sm1
+ +++ b/sm1
+ @@ -1 +1 @@
+ -Subproject commit $fullhead1
+ +Subproject commit $fullhead2
+ EOF
test_cmp expected actual
-"
+'
commit_file sm1 &&
head3=$(
@@ -135,29 +135,28 @@ head3=$(
git rev-parse --short --verify HEAD
)
-test_expect_success 'modified submodule(backward)' "
+test_expect_success 'modified submodule(backward)' '
git diff-index -p --submodule=log HEAD >actual &&
cat >expected <<-EOF &&
-Submodule sm1 $head2..$head3 (rewind):
- < Add foo3
- < Add foo2
-EOF
+ Submodule sm1 $head2..$head3 (rewind):
+ < Add foo3
+ < Add foo2
+ EOF
test_cmp expected actual
-"
+'
-head4=$(add_file sm1 foo4 foo5) &&
-head4_full=$(GIT_DIR=sm1/.git git rev-parse --verify HEAD)
-test_expect_success 'modified submodule(backward and forward)' "
+head4=$(add_file sm1 foo4 foo5)
+test_expect_success 'modified submodule(backward and forward)' '
git diff-index -p --submodule=log HEAD >actual &&
cat >expected <<-EOF &&
-Submodule sm1 $head2...$head4:
- > Add foo5
- > Add foo4
- < Add foo3
- < Add foo2
-EOF
+ Submodule sm1 $head2...$head4:
+ > Add foo5
+ > Add foo4
+ < Add foo3
+ < Add foo2
+ EOF
test_cmp expected actual
-"
+'
commit_file sm1 &&
mv sm1 sm1-bak &&
@@ -167,319 +166,319 @@ git add sm1 &&
rm -f sm1 &&
mv sm1-bak sm1
-test_expect_success 'typechanged submodule(submodule->blob), --cached' "
+test_expect_success 'typechanged submodule(submodule->blob), --cached' '
git diff --submodule=log --cached >actual &&
cat >expected <<-EOF &&
-Submodule sm1 $head4...0000000 (submodule deleted)
-diff --git a/sm1 b/sm1
-new file mode 100644
-index 0000000..$head5
---- /dev/null
-+++ b/sm1
-@@ -0,0 +1 @@
-+sm1
-EOF
+ Submodule sm1 $head4...0000000 (submodule deleted)
+ diff --git a/sm1 b/sm1
+ new file mode 100644
+ index 0000000..$head5
+ --- /dev/null
+ +++ b/sm1
+ @@ -0,0 +1 @@
+ +sm1
+ EOF
test_cmp expected actual
-"
+'
-test_expect_success 'typechanged submodule(submodule->blob)' "
+test_expect_success 'typechanged submodule(submodule->blob)' '
git diff --submodule=log >actual &&
cat >expected <<-EOF &&
-diff --git a/sm1 b/sm1
-deleted file mode 100644
-index $head5..0000000
---- a/sm1
-+++ /dev/null
-@@ -1 +0,0 @@
--sm1
-Submodule sm1 0000000...$head4 (new submodule)
-EOF
+ diff --git a/sm1 b/sm1
+ deleted file mode 100644
+ index $head5..0000000
+ --- a/sm1
+ +++ /dev/null
+ @@ -1 +0,0 @@
+ -sm1
+ Submodule sm1 0000000...$head4 (new submodule)
+ EOF
test_cmp expected actual
-"
+'
rm -rf sm1 &&
git checkout-index sm1
-test_expect_success 'typechanged submodule(submodule->blob)' "
+test_expect_success 'typechanged submodule(submodule->blob)' '
git diff-index -p --submodule=log HEAD >actual &&
cat >expected <<-EOF &&
-Submodule sm1 $head4...0000000 (submodule deleted)
-diff --git a/sm1 b/sm1
-new file mode 100644
-index 0000000..$head5
---- /dev/null
-+++ b/sm1
-@@ -0,0 +1 @@
-+sm1
-EOF
+ Submodule sm1 $head4...0000000 (submodule deleted)
+ diff --git a/sm1 b/sm1
+ new file mode 100644
+ index 0000000..$head5
+ --- /dev/null
+ +++ b/sm1
+ @@ -0,0 +1 @@
+ +sm1
+ EOF
test_cmp expected actual
-"
+'
rm -f sm1 &&
test_create_repo sm1 &&
head6=$(add_file sm1 foo6 foo7)
-test_expect_success 'nonexistent commit' "
fullhead6=$(cd sm1; git rev-parse --verify $head6)
+test_expect_success 'nonexistent commit' '
git diff-index -p --submodule=log HEAD >actual &&
cat >expected <<-EOF &&
-Submodule sm1 $head4...$head6 (commits not present)
-EOF
+ Submodule sm1 $head4...$head6 (commits not present)
+ EOF
test_cmp expected actual
-"
+'
commit_file
-test_expect_success 'typechanged submodule(blob->submodule)' "
+test_expect_success 'typechanged submodule(blob->submodule)' '
git diff-index -p --submodule=log HEAD >actual &&
cat >expected <<-EOF &&
-diff --git a/sm1 b/sm1
-deleted file mode 100644
-index $head5..0000000
---- a/sm1
-+++ /dev/null
-@@ -1 +0,0 @@
--sm1
-Submodule sm1 0000000...$head6 (new submodule)
-EOF
+ diff --git a/sm1 b/sm1
+ deleted file mode 100644
+ index $head5..0000000
+ --- a/sm1
+ +++ /dev/null
+ @@ -1 +0,0 @@
+ -sm1
+ Submodule sm1 0000000...$head6 (new submodule)
+ EOF
test_cmp expected actual
-"
+'
commit_file sm1 &&
-test_expect_success 'submodule is up to date' "
+test_expect_success 'submodule is up to date' '
git diff-index -p --submodule=log HEAD >actual &&
cat >expected <<-EOF &&
-EOF
+ EOF
test_cmp expected actual
-"
+'
-test_expect_success 'submodule contains untracked content' "
+test_expect_success 'submodule contains untracked content' '
echo new > sm1/new-file &&
git diff-index -p --submodule=log HEAD >actual &&
cat >expected <<-EOF &&
-Submodule sm1 contains untracked content
-EOF
+ Submodule sm1 contains untracked content
+ EOF
test_cmp expected actual
-"
+'
-test_expect_success 'submodule contains untracked content (untracked ignored)' "
+test_expect_success 'submodule contains untracked content (untracked ignored)' '
git diff-index -p --ignore-submodules=untracked --submodule=log HEAD >actual &&
! test -s actual
-"
+'
-test_expect_success 'submodule contains untracked content (dirty ignored)' "
+test_expect_success 'submodule contains untracked content (dirty ignored)' '
git diff-index -p --ignore-submodules=dirty --submodule=log HEAD >actual &&
! test -s actual
-"
+'
-test_expect_success 'submodule contains untracked content (all ignored)' "
+test_expect_success 'submodule contains untracked content (all ignored)' '
git diff-index -p --ignore-submodules=all --submodule=log HEAD >actual &&
! test -s actual
-"
+'
-test_expect_success 'submodule contains untracked and modifed content' "
+test_expect_success 'submodule contains untracked and modifed content' '
echo new > sm1/foo6 &&
git diff-index -p --submodule=log HEAD >actual &&
cat >expected <<-EOF &&
-Submodule sm1 contains untracked content
-Submodule sm1 contains modified content
-EOF
+ Submodule sm1 contains untracked content
+ Submodule sm1 contains modified content
+ EOF
test_cmp expected actual
-"
+'
-test_expect_success 'submodule contains untracked and modifed content (untracked ignored)' "
+test_expect_success 'submodule contains untracked and modifed content (untracked ignored)' '
echo new > sm1/foo6 &&
git diff-index -p --ignore-submodules=untracked --submodule=log HEAD >actual &&
cat >expected <<-EOF &&
-Submodule sm1 contains modified content
-EOF
+ Submodule sm1 contains modified content
+ EOF
test_cmp expected actual
-"
+'
-test_expect_success 'submodule contains untracked and modifed content (dirty ignored)' "
+test_expect_success 'submodule contains untracked and modifed content (dirty ignored)' '
echo new > sm1/foo6 &&
git diff-index -p --ignore-submodules=dirty --submodule=log HEAD >actual &&
! test -s actual
-"
+'
-test_expect_success 'submodule contains untracked and modifed content (all ignored)' "
+test_expect_success 'submodule contains untracked and modifed content (all ignored)' '
echo new > sm1/foo6 &&
git diff-index -p --ignore-submodules --submodule=log HEAD >actual &&
! test -s actual
-"
+'
-test_expect_success 'submodule contains modifed content' "
+test_expect_success 'submodule contains modifed content' '
rm -f sm1/new-file &&
git diff-index -p --submodule=log HEAD >actual &&
cat >expected <<-EOF &&
-Submodule sm1 contains modified content
-EOF
+ Submodule sm1 contains modified content
+ EOF
test_cmp expected actual
-"
+'
(cd sm1; git commit -mchange foo6 >/dev/null) &&
-test_expect_success 'submodule is modified' "
head8=$(cd sm1; git rev-parse --short --verify HEAD) &&
+test_expect_success 'submodule is modified' '
git diff-index -p --submodule=log HEAD >actual &&
cat >expected <<-EOF &&
-Submodule sm1 $head6..$head8:
- > change
-EOF
+ Submodule sm1 $head6..$head8:
+ > change
+ EOF
test_cmp expected actual
-"
+'
-test_expect_success 'modified submodule contains untracked content' "
+test_expect_success 'modified submodule contains untracked content' '
echo new > sm1/new-file &&
git diff-index -p --submodule=log HEAD >actual &&
cat >expected <<-EOF &&
-Submodule sm1 contains untracked content
-Submodule sm1 $head6..$head8:
- > change
-EOF
+ Submodule sm1 contains untracked content
+ Submodule sm1 $head6..$head8:
+ > change
+ EOF
test_cmp expected actual
-"
+'
-test_expect_success 'modified submodule contains untracked content (untracked ignored)' "
+test_expect_success 'modified submodule contains untracked content (untracked ignored)' '
git diff-index -p --ignore-submodules=untracked --submodule=log HEAD >actual &&
cat >expected <<-EOF &&
-Submodule sm1 $head6..$head8:
- > change
-EOF
+ Submodule sm1 $head6..$head8:
+ > change
+ EOF
test_cmp expected actual
-"
+'
-test_expect_success 'modified submodule contains untracked content (dirty ignored)' "
+test_expect_success 'modified submodule contains untracked content (dirty ignored)' '
git diff-index -p --ignore-submodules=dirty --submodule=log HEAD >actual &&
cat >expected <<-EOF &&
-Submodule sm1 $head6..$head8:
- > change
-EOF
+ Submodule sm1 $head6..$head8:
+ > change
+ EOF
test_cmp expected actual
-"
+'
-test_expect_success 'modified submodule contains untracked content (all ignored)' "
+test_expect_success 'modified submodule contains untracked content (all ignored)' '
git diff-index -p --ignore-submodules=all --submodule=log HEAD >actual &&
! test -s actual
-"
+'
-test_expect_success 'modified submodule contains untracked and modifed content' "
+test_expect_success 'modified submodule contains untracked and modifed content' '
echo modification >> sm1/foo6 &&
git diff-index -p --submodule=log HEAD >actual &&
cat >expected <<-EOF &&
-Submodule sm1 contains untracked content
-Submodule sm1 contains modified content
-Submodule sm1 $head6..$head8:
- > change
-EOF
+ Submodule sm1 contains untracked content
+ Submodule sm1 contains modified content
+ Submodule sm1 $head6..$head8:
+ > change
+ EOF
test_cmp expected actual
-"
+'
-test_expect_success 'modified submodule contains untracked and modifed content (untracked ignored)' "
+test_expect_success 'modified submodule contains untracked and modifed content (untracked ignored)' '
echo modification >> sm1/foo6 &&
git diff-index -p --ignore-submodules=untracked --submodule=log HEAD >actual &&
cat >expected <<-EOF &&
-Submodule sm1 contains modified content
-Submodule sm1 $head6..$head8:
- > change
-EOF
+ Submodule sm1 contains modified content
+ Submodule sm1 $head6..$head8:
+ > change
+ EOF
test_cmp expected actual
-"
+'
-test_expect_success 'modified submodule contains untracked and modifed content (dirty ignored)' "
+test_expect_success 'modified submodule contains untracked and modifed content (dirty ignored)' '
echo modification >> sm1/foo6 &&
git diff-index -p --ignore-submodules=dirty --submodule=log HEAD >actual &&
cat >expected <<-EOF &&
-Submodule sm1 $head6..$head8:
- > change
-EOF
+ Submodule sm1 $head6..$head8:
+ > change
+ EOF
test_cmp expected actual
-"
+'
-test_expect_success 'modified submodule contains untracked and modifed content (all ignored)' "
+test_expect_success 'modified submodule contains untracked and modifed content (all ignored)' '
echo modification >> sm1/foo6 &&
git diff-index -p --ignore-submodules --submodule=log HEAD >actual &&
! test -s actual
-"
+'
-test_expect_success 'modified submodule contains modifed content' "
+test_expect_success 'modified submodule contains modifed content' '
rm -f sm1/new-file &&
git diff-index -p --submodule=log HEAD >actual &&
cat >expected <<-EOF &&
-Submodule sm1 contains modified content
-Submodule sm1 $head6..$head8:
- > change
-EOF
+ Submodule sm1 contains modified content
+ Submodule sm1 $head6..$head8:
+ > change
+ EOF
test_cmp expected actual
-"
+'
rm -rf sm1
-test_expect_success 'deleted submodule' "
+test_expect_success 'deleted submodule' '
git diff-index -p --submodule=log HEAD >actual &&
cat >expected <<-EOF &&
-Submodule sm1 $head6...0000000 (submodule deleted)
-EOF
+ Submodule sm1 $head6...0000000 (submodule deleted)
+ EOF
test_cmp expected actual
-"
+'
test_create_repo sm2 &&
head7=$(add_file sm2 foo8 foo9) &&
git add sm2
-test_expect_success 'multiple submodules' "
+test_expect_success 'multiple submodules' '
git diff-index -p --submodule=log HEAD >actual &&
cat >expected <<-EOF &&
-Submodule sm1 $head6...0000000 (submodule deleted)
-Submodule sm2 0000000...$head7 (new submodule)
-EOF
+ Submodule sm1 $head6...0000000 (submodule deleted)
+ Submodule sm2 0000000...$head7 (new submodule)
+ EOF
test_cmp expected actual
-"
+'
-test_expect_success 'path filter' "
+test_expect_success 'path filter' '
git diff-index -p --submodule=log HEAD sm2 >actual &&
cat >expected <<-EOF &&
-Submodule sm2 0000000...$head7 (new submodule)
-EOF
+ Submodule sm2 0000000...$head7 (new submodule)
+ EOF
test_cmp expected actual
-"
+'
commit_file sm2
-test_expect_success 'given commit' "
+test_expect_success 'given commit' '
git diff-index -p --submodule=log HEAD^ >actual &&
cat >expected <<-EOF &&
-Submodule sm1 $head6...0000000 (submodule deleted)
-Submodule sm2 0000000...$head7 (new submodule)
-EOF
+ Submodule sm1 $head6...0000000 (submodule deleted)
+ Submodule sm2 0000000...$head7 (new submodule)
+ EOF
test_cmp expected actual
-"
+'
-test_expect_success 'given commit --submodule' "
+test_expect_success 'given commit --submodule' '
git diff-index -p --submodule HEAD^ >actual &&
cat >expected <<-EOF &&
-Submodule sm1 $head6...0000000 (submodule deleted)
-Submodule sm2 0000000...$head7 (new submodule)
-EOF
+ Submodule sm1 $head6...0000000 (submodule deleted)
+ Submodule sm2 0000000...$head7 (new submodule)
+ EOF
test_cmp expected actual
-"
+'
fullhead7=$(cd sm2; git rev-parse --verify $head7)
-test_expect_success 'given commit --submodule=short' "
+test_expect_success 'given commit --submodule=short' '
git diff-index -p --submodule=short HEAD^ >actual &&
cat >expected <<-EOF &&
-diff --git a/sm1 b/sm1
-deleted file mode 160000
-index $head6..0000000
---- a/sm1
-+++ /dev/null
-@@ -1 +0,0 @@
--Subproject commit $fullhead6
-diff --git a/sm2 b/sm2
-new file mode 160000
-index 0000000..$head7
---- /dev/null
-+++ b/sm2
-@@ -0,0 +1 @@
-+Subproject commit $fullhead7
-EOF
- test_cmp expected actual
-"
+ diff --git a/sm1 b/sm1
+ deleted file mode 160000
+ index $head6..0000000
+ --- a/sm1
+ +++ /dev/null
+ @@ -1 +0,0 @@
+ -Subproject commit $fullhead6
+ diff --git a/sm2 b/sm2
+ new file mode 160000
+ index 0000000..$head7
+ --- /dev/null
+ +++ b/sm2
+ @@ -0,0 +1 @@
+ +Subproject commit $fullhead7
+ EOF
+ test_cmp expected actual
+'
test_expect_success 'setup .git file for sm2' '
(cd sm2 &&
@@ -491,9 +490,9 @@ test_expect_success 'setup .git file for sm2' '
test_expect_success 'diff --submodule with .git file' '
git diff --submodule HEAD^ >actual &&
cat >expected <<-EOF &&
-Submodule sm1 $head6...0000000 (submodule deleted)
-Submodule sm2 0000000...$head7 (new submodule)
-EOF
+ Submodule sm1 $head6...0000000 (submodule deleted)
+ Submodule sm2 0000000...$head7 (new submodule)
+ EOF
test_cmp expected actual
'
--
1.7.8.1.362.g5d6df.dirty
^ permalink raw reply related
* Re: Python extension commands in git - request for policy change
From: Felipe Contreras @ 2012-11-27 8:43 UTC (permalink / raw)
To: David Aguilar; +Cc: esr, Nguyen Thai Ngoc Duy, git, msysGit
In-Reply-To: <CAJDDKr4cr3VXqx=CXgXSQrVTSjE=f=55HZns-xfNziJOXb3Vsw@mail.gmail.com>
On Tue, Nov 27, 2012 at 8:54 AM, David Aguilar <davvid@gmail.com> wrote:
> On Mon, Nov 26, 2012 at 5:11 AM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
>> http://www.mediawiki.org/wiki/Git/Graphical_User_Interfaces
>
> *cough* git-cola *cough*
>
> it runs everywhere. Yes, windows too. It's written in python.
> It's been actively maintained since 2007.
% sudo pacman -S git-cola
error: target not found: git-cola
http://aur.archlinux.org/packages/gi/git-cola/git-cola.tar.gz
% makepkg
==> Missing Dependencies:
-> python2-pyqt>=4.3
==> Checking buildtime dependencies...
==> Missing Dependencies:
-> asciidoc
-> docbook-xsl
-> rsync
-> xmlto
-> python2-sphinx>=1.1.3
Sorry, no.
I'm not sure if you have been following, but msysgit doesn't seem to
have good support for python, let alone Qt. In my view the fact that
it uses python is not a good thing.
> It's "modern" and has features that don't exist anywhere else.
>
> It even has tests. It even comes with a building full of willing
> guinea-pigs^Wtesters that let me know right away when
> anything goes wrong.
>
> It uses Qt but that's really the whole point of Qt -> cross-platform.
> (not sure how that wiki page ended up saying Gnome/GTK?)
Yes, Qt is cross-platform *in theory*, but have you used any Qt
application in Windows? I haven't.
> The DAG aka git-dag (in its master branch, about to be released)
> is nicer looking then gitk IMO. gitk still has some features
> that are better too--there's no silver bullet, but the delta
> is pretty small.
If you mean this one:
http://1.1.1.5/bmi/git-cola.github.com/images/dag.png
Then I wholeheartedly disagree.
> The only point this doesn't fulfill is dependency-free-ness.
> With that requirement the answer can *only* be tcl/tk.
> So saying, "go look for one you won't find it" is really
> a tautology. It's not even an entertaining one.
That's the whole point; there is nothing else. If there was something
else, there would be something else. But there isn't.
> When the requirement is, "what is the best user experience
> possible", then you use a mature GUI library. These are different
> requirements and probably different use cases.
But those are not the requirements.
> Anyways, just sayin', you make it sound like this stuff doesn't
> exist, but it does. I've never proposed it for mainline
> git because I'm very aware of the dependency requirements.
A lot of stuff exists. And people use a lot of those. But they don't
fulfill the requirements that I think gitk does perfectly.
> But, if git "recommended" it I would very much appreciate the
> extra eyes and contributions. Being in mainline git could
> possibly help with that. A submodule under contrib/
> would be an interesting experiment.
It might be, if somebody actually tried to submit the code. But I
honestly doubt so.
> In any case, I think documenting the python standards
> (even if within contrib/ only) is a good thing.
>
> We'd be increasing the overall portability by documenting
> what we support and sticking to it, just
> like what is done for shell scripts and perl versions.
> Eric is helping make that happen, let's not throw
> out the baby with the bathwater. FWIW, I would also make
> my python expertise available.
Nobody has argued that there shouldn't be guidelines for python code.
What I have objected is to 'strict rules'.
> This thread has gotten into meta-meta territory --
> it's discussing code that has not yet even been written,
> and going off on all sorts of tangents.
That is the point; why should we change the policy for code that
hasn't been written yet? That's not how things evolve in git as far as
I have seen.
> BTW, Felipe, if you're going to be rewriting python code to ruby,
> please, pretty please rewrite that darn GUI ;-)
I would need to write a widget toolkit first =/ I think I'll pass. gitk is fine.
Cheers.
--
Felipe Contreras
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
^ permalink raw reply
* Re: gitpacker progress report and a question
From: Felipe Contreras @ 2012-11-27 8:51 UTC (permalink / raw)
To: esr; +Cc: git
In-Reply-To: <20121127083639.GA26935@thyrsus.com>
On Tue, Nov 27, 2012 at 9:36 AM, Eric S. Raymond <esr@thyrsus.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com>:
>> Most of those old projects have a linear history,
>
> INTERCAL didn't. There were two branches for platform ports.
Fine:
tag v0.1 gst-av-0.1.tar "Release 0.1"
tag v0.2 gst-av-0.2.tar "Release 0.2"
checkout port1
tag v0.2-p1 gst-av-0.2-p1.tar "Release 0.2 p1"
checkout port2 v0.2
tag v0.2-p2 gst-av-0.2-p2.tar "Release 0.2 p2"
checkout master
tag v0.3 gst-av-0.3.tar "Release 0.3"
Problem solved.
>> But different commit/author and respective dates, and merges? Sounds
>> like overkill.
>
> I felt it was important that the metadata format be able to specify
> git's entire metadata and DAG semantics. Otherwise, as sure as the
> sun rises, *somebody* would run into a corner case not covered, and
> (quite rightly) curse me for a shortsighted fool who had done a
> half-assed job.
I'm willing to bet that won't happen.
> I don't do half-assed jobs. Not ever, no way, nohow.
So you prefer code that is way more complicated that it needs to be,
and with a higher likelihood of introducing bugs? There's a point of
diminishing returns where the code that nobody uses causes bugs for
real use-cases. That's not good.
I prefer code that does one thing, and does it well. And when the need
arises, evolve.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* [PATCH 0.5/4] t4041 (diff-submodule-option): don't hardcode SHA-1 in expected outputs
From: Ramkumar Ramachandra @ 2012-11-27 9:06 UTC (permalink / raw)
To: Git List
The expected SHA-1 digests are always available in variables. Use
them instead of hardcoding.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
---
Oops, I forgot to send this part. It comes before part 1, and it's
essential to make tests pass.
t/t4041-diff-submodule-option.sh | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/t/t4041-diff-submodule-option.sh b/t/t4041-diff-submodule-option.sh
index 57e8a9d..5377639 100755
--- a/t/t4041-diff-submodule-option.sh
+++ b/t/t4041-diff-submodule-option.sh
@@ -62,7 +62,7 @@ test_expect_success '--submodule=short overrides
diff.submodule' "
cat >expected <<-EOF &&
diff --git a/sm1 b/sm1
new file mode 160000
-index 0000000..a2c4dab
+index 0000000..$head1
--- /dev/null
+++ b/sm1
@@ -0,0 +1 @@
@@ -77,7 +77,7 @@ test_expect_success 'diff.submodule does not affect
plumbing' '
cat >expected <<-EOF &&
diff --git a/sm1 b/sm1
new file mode 160000
- index 0000000..a2c4dab
+ index 0000000..$head1
--- /dev/null
+++ b/sm1
@@ -0,0 +1 @@
@@ -173,10 +173,10 @@ mv sm1-bak sm1
test_expect_success 'typechanged submodule(submodule->blob), --cached' "
git diff --submodule=log --cached >actual &&
cat >expected <<-EOF &&
-Submodule sm1 41fbea9...0000000 (submodule deleted)
+Submodule sm1 $head4...0000000 (submodule deleted)
diff --git a/sm1 b/sm1
new file mode 100644
-index 0000000..9da5fb8
+index 0000000..$head5
--- /dev/null
+++ b/sm1
@@ -0,0 +1 @@
@@ -190,7 +190,7 @@ test_expect_success 'typechanged
submodule(submodule->blob)' "
cat >expected <<-EOF &&
diff --git a/sm1 b/sm1
deleted file mode 100644
-index 9da5fb8..0000000
+index $head5..0000000
--- a/sm1
+++ /dev/null
@@ -1 +0,0 @@
--
1.7.12.1.428.g652398a.dirty
^ permalink raw reply related
* Re: [PATCH 0.5/4] t4041 (diff-submodule-option): don't hardcode SHA-1 in expected outputs
From: Ramkumar Ramachandra @ 2012-11-27 9:12 UTC (permalink / raw)
To: Git List
In-Reply-To: <CALkWK0=0SfOuKRZvgt=BOBsKTXtaO5Y7-wAWK4XftE_aY9idyA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 64 bytes --]
Ugh, line wrapping breaks my patch. I've attached a copy.
Ram
[-- Attachment #2: 0001-t4041-diff-submodule-option-don-t-hardcode-SHA-1-in-.patch --]
[-- Type: application/octet-stream, Size: 1891 bytes --]
From 90bc75b78a6dd5e59d2055b05c065447bf051bb6 Mon Sep 17 00:00:00 2001
From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Mon, 26 Nov 2012 19:24:28 +0530
Subject: [PATCH] t4041 (diff-submodule-option): don't hardcode SHA-1 in
expected outputs
The expected SHA-1 digests are always available in variables. Use
them instead of hardcoding.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
---
t/t4041-diff-submodule-option.sh | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/t/t4041-diff-submodule-option.sh b/t/t4041-diff-submodule-option.sh
index 57e8a9d..5377639 100755
--- a/t/t4041-diff-submodule-option.sh
+++ b/t/t4041-diff-submodule-option.sh
@@ -62,7 +62,7 @@ test_expect_success '--submodule=short overrides diff.submodule' "
cat >expected <<-EOF &&
diff --git a/sm1 b/sm1
new file mode 160000
-index 0000000..a2c4dab
+index 0000000..$head1
--- /dev/null
+++ b/sm1
@@ -0,0 +1 @@
@@ -77,7 +77,7 @@ test_expect_success 'diff.submodule does not affect plumbing' '
cat >expected <<-EOF &&
diff --git a/sm1 b/sm1
new file mode 160000
- index 0000000..a2c4dab
+ index 0000000..$head1
--- /dev/null
+++ b/sm1
@@ -0,0 +1 @@
@@ -173,10 +173,10 @@ mv sm1-bak sm1
test_expect_success 'typechanged submodule(submodule->blob), --cached' "
git diff --submodule=log --cached >actual &&
cat >expected <<-EOF &&
-Submodule sm1 41fbea9...0000000 (submodule deleted)
+Submodule sm1 $head4...0000000 (submodule deleted)
diff --git a/sm1 b/sm1
new file mode 100644
-index 0000000..9da5fb8
+index 0000000..$head5
--- /dev/null
+++ b/sm1
@@ -0,0 +1 @@
@@ -190,7 +190,7 @@ test_expect_success 'typechanged submodule(submodule->blob)' "
cat >expected <<-EOF &&
diff --git a/sm1 b/sm1
deleted file mode 100644
-index 9da5fb8..0000000
+index $head5..0000000
--- a/sm1
+++ /dev/null
@@ -1 +0,0 @@
--
1.7.12.1.428.g652398a.dirty
^ permalink raw reply related
* Re: Python extension commands in git - request for policy change
From: Sitaram Chamarty @ 2012-11-27 9:17 UTC (permalink / raw)
To: David Aguilar; +Cc: Felipe Contreras, esr, Nguyen Thai Ngoc Duy, git, msysGit
In-Reply-To: <CAJDDKr4cr3VXqx=CXgXSQrVTSjE=f=55HZns-xfNziJOXb3Vsw@mail.gmail.com>
On Tue, Nov 27, 2012 at 1:24 PM, David Aguilar <davvid@gmail.com> wrote:
> *cough* git-cola *cough*
>
> it runs everywhere. Yes, windows too. It's written in python.
> It's been actively maintained since 2007.
>
> It's "modern" and has features that don't exist anywhere else.
>
> It even has tests. It even comes with a building full of willing
> guinea-pigs^Wtesters that let me know right away when
> anything goes wrong.
>
> It uses Qt but that's really the whole point of Qt -> cross-platform.
> (not sure how that wiki page ended up saying Gnome/GTK?)
>
> The DAG aka git-dag (in its master branch, about to be released)
> is nicer looking then gitk IMO. gitk still has some features
> that are better too--there's no silver bullet, but the delta
> is pretty small.
Gitk does a lot of things that people don't realise, since they're not
really documented and you have to scrounge around on the UI. The
thing is, it's just about the most awesome tool for code archeology I
have seen.
I realise (from looking at the doc page) that git-cola helps you do
all sorts of things, but those are all things I am happier doing at
the command line.
Gitk does precisely those things which *require* a GUI, where the
amount of information presented overwhelms a text interface. The
display is concisely designed to give you the maximum information at a
minimum space use. For example, a little black square when a commit
has a note attached. Even hovering over the arrow-heads, on complex
trees where the line gets broken, does something meaningful.
if I had to pin it down, the feature I use most often is "Show origin
of this line". Other features I use often are
- review a commit file by file (f and b keys, also spacebar and 'd')
- search by SHA1 (4 digits appear to be enough, regardless of how
big your repo is),
- search for commits changing path/dir (while still showing all the
commits; i.e., this is not 'git-dag -- README.txt' but within gitk you
search up and down for commits touching README.txt
- and navigating the commit tree looking for stuff
http://sitaramc.github.com/1-basic-usage/gitk.html is my attempt to
document some of the stuff I have found and use.
One final point: the DAG on the right wastes enormous amounts of
space. Purely subjectively, it is almost jarring on the senses. (If
you reduce it, it becomes unreadable).
With all due respect, git-cola/dag isn't anywhere near what gitk does,
at least for people who are not afraid of the command line and only
need the GUI to visualise a truly complex tree.
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
^ permalink raw reply
* Re: Python extension commands in git - request for policy change
From: David Aguilar @ 2012-11-27 10:51 UTC (permalink / raw)
To: Sitaram Chamarty
Cc: Felipe Contreras, esr, Nguyen Thai Ngoc Duy, git, msysGit,
Guillaume DE BURE
In-Reply-To: <CAMK1S_j_F6PQ73zUP9QaDBR6FVd7fMY==D9vxwpwVwRUbfkB4Q@mail.gmail.com>
On Tue, Nov 27, 2012 at 1:17 AM, Sitaram Chamarty <sitaramc@gmail.com> wrote:
> On Tue, Nov 27, 2012 at 1:24 PM, David Aguilar <davvid@gmail.com> wrote:
>
>> *cough* git-cola *cough*
>>
>> it runs everywhere. Yes, windows too. It's written in python.
>> It's been actively maintained since 2007.
>>
>> It's "modern" and has features that don't exist anywhere else.
>>
>> It even has tests. It even comes with a building full of willing
>> guinea-pigs^Wtesters that let me know right away when
>> anything goes wrong.
>>
>> It uses Qt but that's really the whole point of Qt -> cross-platform.
>> (not sure how that wiki page ended up saying Gnome/GTK?)
>>
>> The DAG aka git-dag (in its master branch, about to be released)
>> is nicer looking then gitk IMO. gitk still has some features
>> that are better too--there's no silver bullet, but the delta
>> is pretty small.
>
> Gitk does a lot of things that people don't realise, since they're not
> really documented and you have to scrounge around on the UI. The
> thing is, it's just about the most awesome tool for code archeology I
> have seen.
>
> I realise (from looking at the doc page) that git-cola helps you do
> all sorts of things, but those are all things I am happier doing at
> the command line.
Ditto. There's actually a few small things I use it for,
mainly for teasing apart commits. These days you can use git-gui
for that, but in the old days it was the only way to interactively
select individual lines and stage/unstage/revert them, etc.
I don't think we can line-by-line revert in git-gui yet, though.
Some other small things that I use: ctrl-g, type something
for grep, hit enter twice and I'm in my editor on that
(or any other selected) line. 'spacebar' does xdg-open,
and 'enter' launches the editor in the status widget;
small things. I, too, do most stuff on the command line.
The grep thing is a good example. You have tons of output,
you see the one line that you care about, and you want to jump
there. Clicking on that line and hitting enter is the minimal
effort to do that. You don't have to click because we also
have keyboard navigation. I have a feeling that there's probably
something I'm missing, though.. another way of working (emacs?)
that would render all of this custom GUI stuff pointless.
What I learned about users:
The commit editor is the #1 thing that got my coworkers finally
writing better commit messages. It forces the subject/description
separation and shows yellow, red when the subject gets too long.
It also auto-wraps. IMO it makes sense for git-gui to do
the same these days.
> Gitk does precisely those things which *require* a GUI, where the
> amount of information presented overwhelms a text interface. The
> display is concisely designed to give you the maximum information at a
> minimum space use. For example, a little black square when a commit
> has a note attached. Even hovering over the arrow-heads, on complex
> trees where the line gets broken, does something meaningful.
>
> if I had to pin it down, the feature I use most often is "Show origin
> of this line". Other features I use often are
> - review a commit file by file (f and b keys, also spacebar and 'd')
> - search by SHA1 (4 digits appear to be enough, regardless of how
> big your repo is),
> - search for commits changing path/dir (while still showing all the
> commits; i.e., this is not 'git-dag -- README.txt' but within gitk you
> search up and down for commits touching README.txt
> - and navigating the commit tree looking for stuff
>
> http://sitaramc.github.com/1-basic-usage/gitk.html is my attempt to
> document some of the stuff I have found and use.
Wow, this is awesome.
> One final point: the DAG on the right wastes enormous amounts of
> space. Purely subjectively, it is almost jarring on the senses. (If
> you reduce it, it becomes unreadable).
>
> With all due respect, git-cola/dag isn't anywhere near what gitk does,
> at least for people who are not afraid of the command line and only
> need the GUI to visualise a truly complex tree.
This is really great feedback.
cc:ing Guillaume since he had similar ideas.
thx,
--
David
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
^ permalink raw reply
* Re: [PATCH 5/5] git-send-email: allow edit invalid email address
From: Krzysztof Mazur @ 2012-11-27 10:53 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Felipe Contreras, Andreas Schwab, Felipe Balbi,
Tomi Valkeinen
In-Reply-To: <7v7gp7q5yx.fsf@alter.siamese.dyndns.org>
On Mon, Nov 26, 2012 at 03:50:30PM -0800, Junio C Hamano wrote:
> Krzysztof Mazur <krzysiek@podlesie.net> writes:
>
> > On Mon, Nov 26, 2012 at 02:58:58PM -0800, Junio C Hamano wrote:
> >> Krzysztof Mazur <krzysiek@podlesie.net> writes:
> >>
> >> >> Not having this new code inside "elsif (/^e/) { }" feels somewhat
> >> >> sloppy, even though it is not *too* bad. Also do we know this
> >> >
> >> > ok, I will fix that.
> >> >
> >> >> function will never be used for addresses other than recipients' (I
> >> >> gave a cursory look to see what is done to the $sender and it does
> >> >> not seem to go through this function, tho)?
> >> >
> >> > Yes, this function is called only from validate_address_just()
> >> > to filter @initial_to, @initial_cc, @bcc_list as early as possible,
> >> > and filter @to and @cc added in each email.
> >>
> >> Thanks; when merged to 'pu', this series seems to break t9001. I'll
> >> push the result out with breakages but could you take a look?
> >>
> >
> > Sorry, I tested final version only on an ancient perl 5.8.8 and it really
> > worked there. The third patch is broken:
> >
> > diff --git a/git-send-email.perl b/git-send-email.perl
> > index 9996735..f3bbc16 100755
> > --- a/git-send-email.perl
> > +++ b/git-send-email.perl
> > @@ -1472,7 +1472,7 @@ sub unique_email_list {
> > my @emails;
> >
> > foreach my $entry (@_) {
> > - my $clean = extract_valid_address_or_die($entry))
> > + my $clean = extract_valid_address_or_die($entry);
>
> Ah, ok, I wasn't looking closely enough. Thanks for a quick
> turnaround. Will requeue and push out.
I rechecked that and I've just sent some older broken version. The
patch that I've sent had date Date: Thu, 22 Nov 2012 19:00:25 +0100,
but on my tree I have commit from Date: Thu Nov 22 19:01:55 2012 +0100,
which is exactly the same as the fixed version in your tree.
Thanks,
Krzysiek
^ 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