Re: Python extension commands in git - request for policy change

[David Aguilar]

On Mon, Nov 26, 2012 at 5:11 AM, Felipe Contreras
 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: gitpacker progress report and a question

[Eric S. Raymond]

Felipe Contreras :
> > 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).
-- 
http://www.catb.org/~esr/";>Eric S. Raymond
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Many ladies have already been fanatical search for tiffany uk

[enidy33]

[url=http://www.cheaptiffanyjewellerysale.co.uk/]tiffany uk[/url]  is
certainly maintaining that will available your different singapore jewelry
generates near to the universe so that the human beings with countless many
section benefit your preferred specialist together with lesser tiffany
jewelry. Any guests has got set up a great promote, and this is certainly
super fast rising a new buyer immoral together with producing different
behaviours. Any cir has got longer together with those periods there is end
up viewed as a good trademark which unfortunately illustrates fantastic,
results together with nibble. only one extremely conventional Tiffany picks
happen to be funky tiffanies sounds, specialist tiffany hoops, tiffany
ornament together with charms. Tiffany has got utilised any favors of each
and every exclusive gal towards predicament together with establish
countless defined style of necklace like conventional precious metal armlet
that will precious metal jewelry necklace.
http://www.cheaptiffanyjewellerysale.co.uk





--
View this message in context: 
http://git.661346.n2.nabble.com/Many-ladies-have-already-been-fanatical-search-for-tiffany-uk-tp7572057.html
Sent from the git mailing list archive at Nabble.com.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: gitpacker progress report and a question

[Eric S. Raymond]

Felipe Contreras :
> 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   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.
-- 
http://www.catb.org/~esr/";>Eric S. Raymond
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: gitpacker progress report and a question

[Felipe Contreras]

On Tue, Nov 27, 2012 at 12:43 AM, Eric S. Raymond  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 
  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 000..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 = '12'
+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 

Re: difftool -d symlinks, under what conditions

[David Aguilar]

On Mon, Nov 26, 2012 at 12:23 PM, Matt McClure
 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Interesting git-format-patch bug

[Perry Hutchison]

Junio C Hamano  wrote:
> "Olsen, Alan R"  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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 5/7] push: require force for refs under refs/tags/

[Chris Rorvick]

On Mon, Nov 26, 2012 at 12:57 PM, Junio C Hamano  wrote:
> Chris Rorvick  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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] Support for git aliasing for tcsh completion

[Marc Khouzam]

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 
---

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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 7/7] push: clarify rejection of update to non-commit-ish

[Chris Rorvick]

On Mon, Nov 26, 2012 at 12:53 PM, Junio C Hamano  wrote:
> Chris Rorvick  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 
>> ---
>>  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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/7] push: return reject reasons via a mask

[Chris Rorvick]

On Mon, Nov 26, 2012 at 12:43 PM, Junio C Hamano  wrote:
> Chris Rorvick  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 
>> ---
>
> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Documentation/git-push.txt: fix typo in remote tracking branch path

[Brandon Casey]

On 11/26/2012 5:30 PM, Junio C Hamano wrote:

Brandon Casey  writes:


From: Brandon Casey 

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.
---
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] Documentation: improve phrasing in git-push.txt

[Mark Szepieniec]

The current version contains the sentence:

Further suppose that the other person already pushed changes leading to
A back to the original repository you two obtained the original commit
X.

which doesn't parse for me; I've changed it to

Further suppose that the other person already pushed changes leading to
A back to the original repository from which you two obtained the
original commit X.

Signed-off-by: Mark Szepieniec 
---
 Documentation/git-push.txt |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index fe46c42..6d19d59 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -286,7 +286,8 @@ leading to commit A.  The history looks like this:
 
 
 Further suppose that the other person already pushed changes leading to A
-back to the original repository you two obtained the original commit X.
+back to the original repository from which you two obtained the original
+commit X.
 
 The push done by the other person updated the branch that used to point at
 commit X to point at commit A.  It is a fast-forward.
-- 
1.7.5.4

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Documentation/git-push.txt: fix typo in remote tracking branch path

[Junio C Hamano]

Brandon Casey  writes:

> From: Brandon Casey 
>
> 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.

>
> Signed-off-by: Brandon Casey 
> ---
>  Documentation/git-push.txt |4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
> index fe46c42..a18f929 100644
> --- a/Documentation/git-push.txt
> +++ b/Documentation/git-push.txt
> @@ -387,8 +387,8 @@ the ones in the examples below) can be configured as the 
> default for
>  `git push origin master:satellite/master dev:satellite/dev`::
>   Use the source ref that matches `master` (e.g. `refs/heads/master`)
>   to update the ref that matches `satellite/master` (most probably
> - `refs/remotes/satellite/master`) in the `origin` repository, then
> - do the same for `dev` and `satellite/dev`.
> + `refs/remotes/origin/satellite/master`) in the `origin` repository,
> + then do the same for `dev` and `satellite/dev`.
>  
>  `git push origin HEAD:master`::
>   Push the current branch to the remote ref matching `master` in the
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: gitpacker progress report and a question

[Felipe Contreras]

On Tue, Nov 27, 2012 at 12:43 AM, Eric S. Raymond  wrote:
> Felipe Contreras :
>> Might be easier to just call 'git ls-files --with-three foo', but I
>> don't see the point of those calls:
>
> Ah, much is now explained.  You were looking at an old version.  I had
> in fact already fixed the subdirectories bug (I've updated my
> regression test to check) and have full support for branchy repos,
> preserving tags and branch heads.

So you are criticizing my code saying "it would then be almost
completely useless...", when this is in fact what you sent to the
list.

For the record, here is the output of a test with your script vs.
mine: the output is *exactly the same*:

---
== log ==
* afcbedc (tag: v0.2, master) bump
| * cbd2dce (devel) dev
|/
* 46f1813 (HEAD, test) remove
* df95e41 dot .
* ede0876 with
* d6f10fc extra
* e6362b1 (tag: v0.1) one
== files ==
file
== spaces ==
with

spaces

== dot ==
dot
.

== orig ref ==
refs/heads/test

== script ==
bc9a7d99132f97adeb5d2ca266bd3d8bc64ccb21  /home/felipec/Downloads/gitpacker.txt
Unpacking..(0.13 sec) done.
Packing..(0.28 sec) done.
== log ==
* 5d0b634 (HEAD, master) bump
* 2fe4a6d remove
* 0c27d3b dot .
* 5e36d3f with spaces
* d6f10fc extra
* e6362b1 one
== files ==
file
== spaces ==
with
spaces

== dot ==
dot
.

== orig ref ==
refs/heads/master

== script ==
33edcb28667b683fbb5f8782383f782f73c5e9e1  /home/felipec/bin/git-weave
== log ==
* afcbedc (HEAD, master) bump
* 46f1813 remove
* df95e41 dot .
* ede0876 with
* d6f10fc extra
* e6362b1 one
== files ==
file
== spaces ==
with

spaces

== dot ==
dot
.

== orig ref ==
refs/heads/test
---

Unfortunately, when I enable some testing stuff, this is what your
script throws:
---
== script ==
bc9a7d99132f97adeb5d2ca266bd3d8bc64ccb21  /home/felipec/Downloads/gitpacker.txt
Unpacking..(0.17 sec) done.
Packing..(0.02 sec) done.
Traceback (most recent call last):
  File "/home/felipec/Downloads/gitpacker.txt", line 308, in 
git_pack(indir, outdir, quiet=quiet)
  File "/home/felipec/Downloads/gitpacker.txt", line 171, in git_pack
command += " ".join(map(lambda p: "-p " + commit_id[int(p)],parents))
  File "/home/felipec/Downloads/gitpacker.txt", line 171, in 
command += " ".join(map(lambda p: "-p " + commit_id[int(p)],parents))
IndexError: list index out of range
== log ==
fatal: bad default revision 'HEAD'
== files ==
fatal: tree-ish master not found.
== spaces ==
fatal: ambiguous argument ':/with': unknown revision or path not in
the working tree.
Use '--' to separate paths from revisions, like this:
'git  [...] -- [...]'
== dot ==
fatal: ambiguous argument ':/dot': unknown revision or path not in the
working tree.
Use '--' to separate paths from revisions, like this:
'git  [...] -- [...]'
== orig ref ==
refs/heads/master
---

I'm attaching it in case you are interested.

Anyway, I can add support for branches and tags in no time, but I
wonder what's the point. Who will take so much time and effort to
generate all the branches and tags, and the log file?

If the goal is as you say "importing older projects that are available
only as sequences of release tarballs", then that code is overkill,
and it's not even making it easier to import the tarballs.

For that case my proposed format:

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"

Would be much more suitable.

>> > It doesn't issue delete ops.
>>
>> What do you mean?
>>
>> out.puts 'deleteall' <- All current files are removed
>
> Yours emits no D ops for files removed after a particular snapshot.

man git fast-import

---
This command is extremely useful if the frontend does not know (or
does not care to know) what files are currently on the branch, and
therefore cannot generate the proper filedelete commands to update the
content.
---

Why would I want to emit D operations, again, deleteall takes care of that.

>> > Be aware, however, that I consider easy editability by human beings
>> > much more important than squeezing the last microsecond out of the
>> > processing time.  So, for example, I won't use data byte counts rather
>> > than end delimiters, the way import streams do.
>>
>> Well, if there's a line with a single dot in the commit message ('.'),
>> things would go very bad.
>
> Apparently you missed the part where I byte-stuffed the message content.
> It's a technique used in a lot of old-school Internet protocols, notably
> in SMTP.

You might have done that, but the user that generated the log file
might have not.

>> Personally I would prefer something like this:
>
> There's a certain elegance to that, but it would be hard to generate by hand.

You think this is hard to generate by hand:

---
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"
---

Than this?

---
commit 1
directory gst-av-0.1

Release 0.1
.
commit 2
directory gst-av-0.2

Release 0.2
.
commit 3
directory gst-av-0.3

Release 0.3
.

[PATCH] Documentation/git-push.txt: fix typo in remote tracking branch path

[Brandon Casey]

From: Brandon Casey 

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

Signed-off-by: Brandon Casey 
---
 Documentation/git-push.txt |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index fe46c42..a18f929 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -387,8 +387,8 @@ the ones in the examples below) can be configured as the 
default for
 `git push origin master:satellite/master dev:satellite/dev`::
Use the source ref that matches `master` (e.g. `refs/heads/master`)
to update the ref that matches `satellite/master` (most probably
-   `refs/remotes/satellite/master`) in the `origin` repository, then
-   do the same for `dev` and `satellite/dev`.
+   `refs/remotes/origin/satellite/master`) in the `origin` repository,
+   then do the same for `dev` and `satellite/dev`.
 
 `git push origin HEAD:master`::
Push the current branch to the remote ref matching `master` in the
-- 
1.7.8.4


---
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.
---
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 p1.1 00/14] fast-export and remote-testgit improvements

[Junio C Hamano]

Felipe Contreras  writes:

> On Tue, Nov 27, 2012 at 12:04 AM, Junio C Hamano  wrote:
>> Felipe Contreras  writes:
>>
>>> I'm rerolling this series with the changes fron Junio, plus a bit more 
>>> cleanups.
>>>
>>> I dropped the last patch, because I found an issue and a separate patch 
>>> series
>>> would take care of that. Other than that the main changes remain the same.
>>>
>>> The old remote-testgit is now remote-testpy (as it's testing the python
>>> framework, not really remote helpers). The tests are simplified, and 
>>> exercise
>>> more features of transport-helper, and unsuprisingly, find more bugs.
>>
>> Thanks.
>>
>> I've queued [v6 p1.1] but not later parts (yet).  The result merged
>> to 'pu' however seems to break t5800.  It could be a stupid and
>> trivial merge error or something, but I didn't look into the
>> details.
>
> Yeah, the last patch triggers that. It should be moved to part2. The
> patch "fast-export: don't handle uninteresting refs" should fix that,
> which is why I believe it should be applied first. Didn't I already
> say that?

You may have, but I am leaky ;-) as I am not 100% focused on this
series alone.

In the meantime, I'll drop the last one, push out the 'pu' branch
after rebuilding, and then revisit it when I queue the part 2.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 5/5] git-send-email: allow edit invalid email address

[Junio C Hamano]

Krzysztof Mazur  writes:

> On Mon, Nov 26, 2012 at 02:58:58PM -0800, Junio C Hamano wrote:
>> Krzysztof Mazur  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.

>   $seen{$clean} ||= 0;
>   next if $seen{$clean}++;
>   push @emails, $entry;
>
> Krzysiek
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: gitpacker progress report and a question

[Eric S. Raymond]

Felipe Contreras :
> Might be easier to just call 'git ls-files --with-three foo', but I
> don't see the point of those calls:

Ah, much is now explained.  You were looking at an old version.  I had
in fact already fixed the subdirectories bug (I've updated my
regression test to check) and have full support for branchy repos,
preserving tags and branch heads.

> > It doesn't issue delete ops.
> 
> What do you mean?
> 
> out.puts 'deleteall' <- All current files are removed

Yours emits no D ops for files removed after a particular snapshot.

> > Be aware, however, that I consider easy editability by human beings
> > much more important than squeezing the last microsecond out of the
> > processing time.  So, for example, I won't use data byte counts rather
> > than end delimiters, the way import streams do.
> 
> Well, if there's a line with a single dot in the commit message ('.'),
> things would go very bad.

Apparently you missed the part where I byte-stuffed the message content.
It's a technique used in a lot of old-school Internet protocols, notably
in SMTP.
 
> Personally I would prefer something like this:

There's a certain elegance to that, but it would be hard to generate by hand.

Remember that a major use case for this tool is making repositories 
from projects whose back history exists only as tarballs.  So, let's
say you have the following:

foo-1.1.tar.gz
foo-1.2.tar.gz
foo-1.3.tar.gz

What you're going to do before weaving is drop the untarred file trees
in a 'foo' scratch directory, then hand-craft a log file that might
look a bit like this:

---
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.  
-- 
http://www.catb.org/~esr/";>Eric S. Raymond
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 5/5] git-send-email: allow edit invalid email address

[Krzysztof Mazur]

On Mon, Nov 26, 2012 at 02:58:58PM -0800, Junio C Hamano wrote:
> Krzysztof Mazur  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);
$seen{$clean} ||= 0;
next if $seen{$clean}++;
push @emails, $entry;

Krzysiek
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] emacs: make 'git-status' work with separate git dirs

[Junio C Hamano]

Alexandre Julliard  writes:

> Junio C Hamano  writes:
>
>> Enrico Scholz  writes:
>>
>>> when trying 'M-x git-status' in a submodule created with recent (1.7.5+)
>>> git, the command fails with
>>>
>>> | ... is not a git working tree
>>>
>>> This is caused by creating submodules with '--separate-git-dir' but
>>> still checking for a working tree by testing for a '.git' directory.
>>>
>>> The patch fixes this by relaxing the existing detection a little bit.
>>>
>>> Signed-off-by: Enrico Scholz 
>>> ---
>>
>> This script already relies on the assumption that nobody sane would
>> create a directory named ".git" that is not a git repository, and
>> this loosens the assumption that nobody would create a file named
>> ".git", either.  So I would think it is a sane thing to do, but just
>> in case if the area expert has better ideas, I am forwarding it.
>>
>> Ack?
>
> Sure, that's fine.

Thanks, both.  Applied.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCH] Option to revert order of parents in merge commit

[Aaron Schrab]

At 09:58 -0800 26 Nov 2012, Junio C Hamano  wrote:

Kacper Kornet  writes:

The change of order of parents happens at the very last moment, so
"ours" in merge options is local version and "theirs" upstream.


That may be something that wants to go to the proposed commit log
message.  I am neutral on the "feature" (i.e. not against it but not
extremely enthusiastic about it either).


That should also be included in the (currently nonexistent) 
documentation of the proposed option.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 p1.1 00/14] fast-export and remote-testgit improvements

[Felipe Contreras]

On Tue, Nov 27, 2012 at 12:04 AM, Junio C Hamano  wrote:
> Felipe Contreras  writes:
>
>> I'm rerolling this series with the changes fron Junio, plus a bit more 
>> cleanups.
>>
>> I dropped the last patch, because I found an issue and a separate patch 
>> series
>> would take care of that. Other than that the main changes remain the same.
>>
>> The old remote-testgit is now remote-testpy (as it's testing the python
>> framework, not really remote helpers). The tests are simplified, and exercise
>> more features of transport-helper, and unsuprisingly, find more bugs.
>
> Thanks.
>
> I've queued [v6 p1.1] but not later parts (yet).  The result merged
> to 'pu' however seems to break t5800.  It could be a stupid and
> trivial merge error or something, but I didn't look into the
> details.

Yeah, the last patch triggers that. It should be moved to part2. The
patch "fast-export: don't handle uninteresting refs" should fix that,
which is why I believe it should be applied first. Didn't I already
say that?

Cheers.

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: gitpacker progress report and a question

[Felipe Contreras]

On Mon, Nov 26, 2012 at 11:01 PM, Eric S. Raymond  wrote:
> Felipe Contreras :
>> 1) I tried it, and it doesn't seem to import (pack?) are repository
>> with sub-directories in it
>
> I'll make sure my regression test checks this case.  The options to git
> ls-files are a bit confusing and it's possible my invocation of it
> needs to change.

Might be easier to just call 'git ls-files --with-three foo', but I
don't see the point of those calls:

% git --work-tree=unpacked/1 checkout master
% git --work-tree=unpacked/1 add -A

Should work just fine.

>> 2) Using 'git fast-import' is probably simpler, and more efficient
>
> That might well be.  I'm not worried about "efficiency" in this context
> but reducing the code size is significant and I'm willing to re-code
> to do that.

I don't see how the code-size would increase dramatically.

>> Here is a proof of concept I wrote in ruby that is half the size, and
>> seems to implement the same functionality.
>
> Not anywhere near the same.  It only handles commits, not tags.

The attached code doesn't handle tags either.

> It doesn't issue delete ops.

What do you mean?

out.puts 'deleteall' <- All current files are removed

And then added.

> And it doesn't rebuild branch heads.

What do you mean? Your code only exports a single branch, the branch
that is currently checked out. And then:

git reset --hard >/dev/null; git checkout master >/dev/null 2>&1

It's resuming to 'master', which might not be the branch the user had
checkout out, and might not even exist.

> If I were willing to omit those features, I'm sure I could halve
> the size of my implementation, too.  Of course, it would then be
> almost completely useless...

That's what the code currently does.

Do you want me to show you step by step how they do *exactly the
same*? Of course, I would need to fix your version first so that it
doesn't crash with sub-directories.

>>   The format is exactly the
>> same, but I think it should be modified to be more efficient.
>
> I'm not wedded to the log format as it is, so I'll cheerfully
> take suggestions about it.
>
> Be aware, however, that I consider easy editability by human beings
> much more important than squeezing the last microsecond out of the
> processing time.  So, for example, I won't use data byte counts rather
> than end delimiters, the way import streams do.

Well, if there's a line with a single dot in the commit message ('.'),
things would go very bad.

Personally I would prefer something like this:

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 the script in bash would be very simple:

#!/bin/sh

tag() {
d=`mktemp -d` &&
(
cd $d &&
tar -xf "$orig/$2" &&
cd * &&
git add --all &&
git commit -q -m "$3" &&
git tag $1) || error=1
rm -rf $d
test -n "$error" && exit -1
}

orig="$PWD"
repo="$1"

git init -q $repo
export GIT_DIR="$orig/$repo/.git"

source "$orig/$2"

cd "$orig/$repo" && git reset -q --hard

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 p1.1 00/14] fast-export and remote-testgit improvements

[Junio C Hamano]

Felipe Contreras  writes:

> I'm rerolling this series with the changes fron Junio, plus a bit more 
> cleanups.
>
> I dropped the last patch, because I found an issue and a separate patch series
> would take care of that. Other than that the main changes remain the same.
>
> The old remote-testgit is now remote-testpy (as it's testing the python
> framework, not really remote helpers). The tests are simplified, and exercise
> more features of transport-helper, and unsuprisingly, find more bugs.

Thanks.

I've queued [v6 p1.1] but not later parts (yet).  The result merged
to 'pu' however seems to break t5800.  It could be a stupid and
trivial merge error or something, but I didn't look into the
details.

Could interested parties take a look? 

$ cd t && sh ./t5800-remote-testpy.sh

ok 1 - setup repository
ok 2 - cloning from local repo
ok 3 - cloning from remote repo
ok 4 - create new commit on remote
ok 5 - pulling from local repo
ok 6 - pulling from remote remote
ok 7 - pushing to local repo
not ok 8 - synch with changes from localclone
#
#   (cd clone &&
#git pull)
#
not ok 9 - pushing remote local repo
#
#   (cd clone &&
#   echo content >>file &&
#   git commit -a -m four &&
#   git push) &&
#   compare_refs clone HEAD server HEAD
#
ok 10 - fetch new branch
not ok 11 - fetch multiple branches
#
#   (cd localclone &&
#git fetch
#   ) &&
#   compare_refs server master localclone 
refs/remotes/origin/master &&
#   compare_refs server new localclone refs/remotes/origin/new
#
not ok 12 - push when remote has extra refs
#
#   (cd clone &&
#echo content >>file &&
#git commit -a -m six &&
#git push
#   ) &&
#   compare_refs clone master server master
#
ok 13 - push new branch by name
not ok 14 - push new branch with old:new refspec # TODO known breakage
ok 15 - proper failure checks for fetching
not ok 16 - proper failure checks for pushing # TODO known breakage
# still have 2 known breakage(s)
# failed 4 among remaining 14 test(s)
1..16
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 5/5] git-send-email: allow edit invalid email address

[Junio C Hamano]

Krzysztof Mazur  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?


Test Summary Report
---
t9001-send-email.sh  (Wstat: 256 Tests: 102 Failed: 
77)
  Failed tests:  4-7, 9-10, 12-13, 15, 17-21, 23-29, 31-33
35, 37, 39, 41, 43, 45, 47, 49, 51-58, 61-88
91, 93-95, 98-102
  Non-zero exit status: 1
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Multiple threads of compression

[Sebastian Leske]

Hi,

[Thorsten Glaser , 2012-11-25 17:27]:
> On a multi-core machine, the garbage collection of git, as well
> as pack compression on the server side when someone clones a
> repository remotely, the compression is normally done automatically
> using multiple threads of execution.
> 
> That may be fine for your typical setups, but in my cases, I have
> two scenarios where it isn’t:
> 
> ⓐ The machine where I want it to use only, say, 2 of my 4 or 8 cores
>   as I’m also running some VMs on the box which eat up a lot of CPU
>   and which I don’t want to slow down.
 
> ⓑ The server VM which has been given 2 or 3 VCPUs to cope with all
>   the load done by clients, but which is RAM-constrained to only
>   512 or, when lucky, 768 MiB. It previously served only http/https
>   and *yuk* Subversion, but now, git comes into the play, and I’ve
>   seen the one server box I think about go down *HARD* because git
>   ate up all RAM *and* swap when someone wanted to update their clone
>   of a repository after someone else committed… well, an ~100 MiB large
>   binary file they shouldn’t.

unfortunately I can't really speak to the git side of things, but both
of these cases just sound like standard resource starvation. So why
don't you address them using the usual OS mechanisms? 

If you want to prevent git from sucking up CPU, nice(1) it, and if it
eats too much RAM, use the parent shell's ulimit mechanism.

Granted, this might also require some changes to git, but wouldn't that
be a simpler and more general approach to solving starvation problems?

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Interesting git-format-patch bug

[Junio C Hamano]

"Olsen, Alan R"  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".

I think you could make your "some other process" that rewrites
commits to cull the duplicates out of the format-patch output,
though.  Each output file identifies what commit object the patch
came from, and your "some other process" that rewrote the commits
ought to know which commit updated which other commit did, which is
the piece of information needed to remove duplicates that format-patch
does not have.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 15/15] fast-export: don't handle uninteresting refs

[Junio C Hamano]

Sverre Rabbelier  writes:

> On Mon, Nov 26, 2012 at 11:26 AM, Johannes Schindelin
>  wrote:
>>> We added rev_cmdline_info since then so that we can tell what refs
>>> were given from the command line in what way, and I thought that we
>>> applied a patch from Sverre that uses it instead of the object
>>> flags.  Am I misremembering things?
>>
>> It does sound so familiar that I am intended to claim that you remember
>> things correctly.
>
> FWIW, I implemented that in
> http://thread.gmane.org/gmane.comp.version-control.git/184874 but
> didn't do the work to get it merged.

Ah, OK.  Should I expect an updated series then?  How would it
interact with the recent work by Felipe?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Third try at documenting command integration requirements.

[Eric S. Raymond]

Junio C Hamano :
> Even though "={n} title ={n}" is a valid AsciiDoc heading, all other
> files use (older) underscored titles; please refrain from being
> original.
> 
> Especially, this interferes with the way the api-index.txt file in
> the same directory is autogenerated.

Noted for the future, thank you.
-- 
http://www.catb.org/~esr/";>Eric S. Raymond
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: gitpacker progress report and a question

[Eric S. Raymond]

Felipe Contreras :
> 1) I tried it, and it doesn't seem to import (pack?) are repository
> with sub-directories in it

I'll make sure my regression test checks this case.  The options to git 
ls-files are a bit confusing and it's possible my invocation of it
needs to change.
 
> 2) Using 'git fast-import' is probably simpler, and more efficient

That might well be.  I'm not worried about "efficiency" in this context 
but reducing the code size is significant and I'm willing to re-code
to do that.
 
> Here is a proof of concept I wrote in ruby that is half the size, and
> seems to implement the same functionality.

Not anywhere near the same.  It only handles commits, not tags. It
doesn't issue delete ops.  And it doesn't rebuild branch heads.
If I were willing to omit those features, I'm sure I could halve
the size of my implementation, too.  Of course, it would then be
almost completely useless...

>   The format is exactly the
> same, but I think it should be modified to be more efficient.

I'm not wedded to the log format as it is, so I'll cheerfully
take suggestions about it.

Be aware, however, that I consider easy editability by human beings
much more important than squeezing the last microsecond out of the
processing time.  So, for example, I won't use data byte counts rather
than end delimiters, the way import streams do.
-- 
http://www.catb.org/~esr/";>Eric S. Raymond
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/11] alternative unify appending of sob

[Junio C Hamano]

Brandon Casey  writes:

> So, this series should result in s-o-b and "(cherry picked from...)" being
> appended to commit messages in a more consistent and deterministic way.  For
> example, the decision about whether to insert a blank line before appending
> a s-o-b.  As discussed, cherry-pick and commit will only refrain from
> appending a s-o-b if the committer's s-o-b appears as the last one in a
> conforming footer, while format-patch will refrain from appending it if it
> appears anywhere within the footer.

Sounds sensible; we may want to fix format-patch later, but with
something like this series, it is just the matter of flipping one
bit.

Will queue. Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 15/15] fast-export: don't handle uninteresting refs

[Sverre Rabbelier]

On Mon, Nov 26, 2012 at 11:26 AM, Johannes Schindelin
 wrote:
>> We added rev_cmdline_info since then so that we can tell what refs
>> were given from the command line in what way, and I thought that we
>> applied a patch from Sverre that uses it instead of the object
>> flags.  Am I misremembering things?
>
> It does sound so familiar that I am intended to claim that you remember
> things correctly.

FWIW, I implemented that in
http://thread.gmane.org/gmane.comp.version-control.git/184874 but
didn't do the work to get it merged.

-- 
Cheers,

Sverre Rabbelier
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Third try at documenting command integration requirements.

[Junio C Hamano]

e...@thyrsus.com (Eric S. Raymond) writes:

> @@ -0,0 +1,91 @@
> += Integrating new subcommands =
> +
> +This is how-to documentation for people who want to add extension
> +commands to git.  It should be read alongside api-builtin.txt.
> +
> +== Runtime environment ==
> +
> +git subcommands are standalone executables that live in the git

Even though "={n} title ={n}" is a valid AsciiDoc heading, all other
files use (older) underscored titles; please refrain from being
original.

Especially, this interferes with the way the api-index.txt file in
the same directory is autogenerated.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Third try at documenting command integration requirements.

[Eric S. Raymond]

Junio C Hamano :
> I'll reword the title (readers of "git log" output 6 months down the
> road will not care if this is the third try or the first one) and
> tweak things here and there before queuing.

Result looks good from here.
 
The next things on my git to-do list are 

1. Audit the in-tree Python for version dependencies.  Add floor-version checks.

2. Submit a doc patch containing guidelines that (a) Python scripts should
   check for their floor version and error out gracefully if they won't
   run with the host's interpreter, and (b) Python scripts sbould be
   2.6-compatible.

3. Submit the git-weave integration patch.  I could do that now, but while my
   regression test speaks TAP it doesn't presently use the test library. I plan
   to re-work it to do that.

Do you have any other pending tasks for which you think my expertise would
be useful?  I refer specifically to the facts that (a) I find writing and 
editing documentation easy and can do it rapidly, (b) I'm a Python expert, 
and (c) I am very interested in, and know a lot about, tools for repository
surgery and import/export.
-- 
http://www.catb.org/~esr/";>Eric S. Raymond
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Interesting git-format-patch bug

[Olsen, Alan R]

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...)

This is should be one of those rare corner case "don't do that" occurrences. 
Unfortunately it does happen once in a while on our branches and it screws up 
some of the automated processes we rely on.

Is there a way around that (other than "don't") or can this be fixed?

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git bundle format [OT]

[Stephen Bash]

- Original Message -
> From: "Jason J CTR Pyeron (US)" 
> Sent: Monday, November 26, 2012 4:06:59 PM
> Subject: RE: git bundle format [OT]
> 
> > First, a shot out of left field: how about a patch based workflow?
> > (similar to the mailing list, just replace email with sneakernet)
> > Patches are plain text and simple to review (preferable to an
> > "opaque" binary format?).
> 
> This is to only address the accidental development on a high side.
> Using this or any process should come with shame or punishment for
> wasting resources/time by not developing on a low side to start
> with.

Ah, if only more of those I (previously) worked with thought as you do :)

> But accepting reality there will be times where code and its
> metadata (commit logs, etc) will be created on a high side and
> should be brought back to the low side.

Using git format-patch and git am it's possible to retain the commit messages 
(and other associated metadata).  But again, I'm not the expert on this :)  
I've made it work a few times to test patches from this list, but so far I've 
avoided serious integration into the mailing list workflow.

> >   2) Do the diffs applied to public repo contain any sensitive
> >   data?
> 
> That is a great question. Can the change of code while neither the
> original or the resultant be secret while the change imply or
> demonstrate the secret. I think the answer is yes.

In actual fact I was thinking about the simple case where the result included 
an "Eek! 3.1415926 cannot show up in this code!" (sometimes that's easier to 
see in a diff than a full text blob).  Obviously the first line of defense 
should catch such mistakes.  But yes, your point is also a good one.  I'd be 
hard pressed to argue that a particular series of commits leaks information on 
their own, but they can certainly corroborate other available information.

> > Question 2 is relatively straight forward and lead me to the patch
> > idea.  I would:
> >   - Bundle the public repository
> >   - Init a new repo in the secure space from the public bundle
> >   - Fetch from the to-be-sanitized bundle into the new repo
> >   - Examine commits (diffs) introduced by branches in the to-be-
> >   sanitized bundle
> >   - Perhaps get a list of all the objects in the to-be-sanitized
> >   bundle and do a git-cat-file on each of them (if the bundle is
> >   assembled correctly it shouldn't have any unreachable objects...).
> >   This step may be extraneous after the previous.
> 
> Here we would be missing the metadata that goes along with the
> commit. Especially the SHA sums.

Ah sorry, I guess I wasn't complete.  Once that process has been done on the 
high side one has to go back to question 1 and see if it's safe to move the 
bundle out to repeat the process on the low side. 
 
Stephen
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Fix typo in remote set-head usage

[Junio C Hamano]

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 15/15] fast-export: don't handle uninteresting refs

[Johannes Schindelin]

Hi Junio,

On Mon, 26 Nov 2012, Junio C Hamano wrote:

> Johannes Schindelin  writes:
> 
> > If you changed your stance on the patch Sverre and I sent to fix this,
> > we could get a non-partial fix for this.
> 
> This is long time ago so I may be misremembering the details, but I
> thought the original patch was (ab)using object flags to mark "this was
> explicitly asked for, even though some other range operation may have
> marked it uninteresting".  Because it predated the introduction of the
> rev_cmdline_info mechanism to record what was mentioned on the command
> line separately from what objects are uninteresting (i.e. object flags),
> it may have been one convenient way to record this information, but it
> still looked unnecessarily ugly hack to me, in that it allocated scarce
> object flag bits to represent a narrow special case (iirc, only a
> freestanding "A" on the command line but not "A" spelled in "B..A", or
> something), making it more expensive to record other kinds of command
> line information in a way consistent with the approach chosen (we do not
> want to waste object flag bits in order to record "this was right hand
> side tip of the symmetric difference range" and such).

Good to know. I will find some time to look at rev_cmdline_info and patch
my patch.

> If you are calling "do not waste object flags to represent one
> special case among endless number of possibilities, as it will make
> it impossible to extend it" my stance, that hasn't changed.
> 
> We added rev_cmdline_info since then so that we can tell what refs
> were given from the command line in what way, and I thought that we
> applied a patch from Sverre that uses it instead of the object
> flags.  Am I misremembering things?

It does sound so familiar that I am intended to claim that you remember
things correctly.

Ciao,
Johannes
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: git bundle format [OT]

[Pyeron, Jason J CTR (US)]

> -Original Message-
> From: Stephen Bash
> Sent: Monday, November 26, 2012 3:56 PM
> 
> - Original Message -
> > From: "Jason J CTR Pyeron (US)" 
> > Sent: Monday, November 26, 2012 2:24:54 PM
> > Subject: git bundle format
> >
> > I am facing a situation where I would like to use git bundle but at
> > the same time inspect the contents to prevent a spillage[1].
> 
> As someone who faced a similar situation in a previous life, I'll offer
> my $0.02, but I'm certainly not the technical expert here.

Kind of what I am looking for as a side effect.

> 
> > Given we have a public repository which was cloned on to a secret
> > development repository. Now the developers do some work which should
> > not be sensitive in any way and commit and push it to the secret
> > repository.
> >
> > Now they want to release it out to the public. The current process is
> > to review the text files to ensure that there is no "secret" sauce
> > in there and then approve its release. This current process ignores
> > the change tracking and all non-content is lost.
> >
> > In this situation we should assume that the bundle does not have any
> > content which is already in the public repository, that is it has
> > the minimum data to make it pass a git bundle verify from the public
> > repositories point of view. We would then take the bundle and pipe
> > it though the "git-bundle2text" program which would result in a
> > "human" inspectable format as opposed to the packed format[2]. The
> > security reviewer would then see all the information being released
> > and with the help of the public repository see how the data changes
> > the repository.
> >
> > Am I barking up the right tree?
> 
> First, a shot out of left field: how about a patch based workflow?
> (similar to the mailing list, just replace email with sneakernet)
> Patches are plain text and simple to review (preferable to an "opaque"
> binary format?).

This is to only address the accidental development on a high side. Using this 
or any process should come with shame or punishment for wasting resources/time 
by not developing on a low side to start with. But accepting reality there will 
be times where code and its metadata (commit logs, etc) will be created on a 
high side and should be brought back to the low side.


> Second, thinking about your proposed bundle-based workflow I have two
> questions I'd have to answer to be comfortable with the solution:
> 
>   1) Does the binary bundle contain any sensitive information?

Potentially, hence the review. If the reviewer cannot prove the data he is 
looking at then the presumption is yes.

>   2) Do the diffs applied to public repo contain any sensitive data?

That is a great question. Can the change of code while neither the original or 
the resultant be secret while the change imply or demonstrate the secret. I 
think the answer is yes.

> 
> Question 1 seems tricky to someone who knows *nothing* about the bundle
> format (e.g. me).  Maybe some form of bundle2text can be vetted enough
> that everyone involved believes that there is no other information
> traveling with the bundle (if so, you're golden).  Here I have to trust
> other experts.  On the flip side, even if the bundle itself is polluted
> (or considered to be lacking proof to the contrary), if (2) is
> considered safe, the patching of the public repo could potentially be
> done on a sacrificial hard drive before pushing.

The logistics are well established and here and now is not a place to go in to 
that. But the above is the crux of what I am trying to get at.
 
> 
> Question 2 is relatively straight forward and lead me to the patch
> idea.  I would:
>   - Bundle the public repository
>   - Init a new repo in the secure space from the public bundle
>   - Fetch from the to-be-sanitized bundle into the new repo
>   - Examine commits (diffs) introduced by branches in the to-be-
> sanitized bundle
>   - Perhaps get a list of all the objects in the to-be-sanitized bundle
> and do a git-cat-file on each of them (if the bundle is assembled
> correctly it shouldn't have any unreachable objects...).  This step may
> be extraneous after the previous.

Here we would be missing the metadata that goes along with the commit. 
Especially the SHA sums.

Thanks.

-Jason


smime.p7s
Description: S/MIME cryptographic signature

[PATCH v4 3/4] git-submodule update: Add --branch option

[W. Trevor King]

From: "W. Trevor King" 

This allows users to checkout the current
superproject-recorded-submodule-sha as a branch, avoiding the detached
head state that the standard submodule update creates.  This may be
useful for the existing --rebase/--merge workflows which already avoid
detached heads.

It is also useful if you want easy tracking of upstream branches.  The
particular upstream branch to be tracked is configured locally with
.git/modules//config.  With the new option Ævar's suggested

  $ git submodule foreach 'git checkout $(git config --file $toplevel/.gitm
odules submodule.$name.branch) && git pull'

reduces to a

  $ git submodule update --branch

after each supermodule .gitmodules edit, and a

  $ git submodule foreach 'git pull'

whenever you feel like updating the submodules.  Your still on you're
own to commit (or not) the updated submodule hashes in the
superproject's .gitmodules.

Signed-off-by: W. Trevor King 
---
 Documentation/git-submodule.txt | 20 +++--
 git-submodule.sh| 48 +--
 t/t7406-submodule-update.sh | 50 -
 3 files changed, 98 insertions(+), 20 deletions(-)

diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index d0b4436..34392a1 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -13,7 +13,7 @@ SYNOPSIS
  [-f|--force] [--reference ] [--]  []
 'git submodule' [--quiet] status [--cached] [--recursive] [--] [...]
 'git submodule' [--quiet] init [--] [...]
-'git submodule' [--quiet] update [--init] [-N|--no-fetch] [--rebase]
+'git submodule' [--quiet] update [--init] [-N|--no-fetch] [--branch] [--rebase]
  [--reference ] [--merge] [--recursive] [--] 
[...]
 'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) ]
  [commit] [--] [...]
@@ -136,11 +136,11 @@ init::
 
 update::
Update the registered submodules, i.e. clone missing submodules and
-   checkout the commit specified in the index of the containing repository.
-   This will make the submodules HEAD be detached unless `--rebase` or
-   `--merge` is specified or the key `submodule.$name.update` is set to
-   `rebase`, `merge` or `none`. `none` can be overridden by specifying
-   `--checkout`.
+   checkout the commit specified in the index of the containing
+   repository.  This will make the submodules HEAD be detached unless
+   `--branch`, `--rebase`, `--merge` is specified or the key
+   `submodule.$name.update` is set to `branch`, `rebase`, `merge` or
+   `none`. `none` can be overridden by specifying `--checkout`.
 +
 If the submodule is not yet initialized, and you just want to use the
 setting as stored in .gitmodules, you can automatically initialize the
@@ -207,7 +207,13 @@ OPTIONS
 
 -b::
 --branch::
-   Branch of repository to add as submodule.
+   When used with the add command, gives the branch of repository to
+   add as submodule.
++
+When used with the update command, checks out a branch named
+`submodule..branch` (as set by `--local-branch`) pointing at the
+current HEAD SHA-1.  This is useful for commands like `update
+--rebase` that do not work on detached heads.
 
 --local-branch::
Record a branch name used as `submodule..branch` in
diff --git a/git-submodule.sh b/git-submodule.sh
index c51b6ae..28eb4b1 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -8,7 +8,7 @@ dashless=$(basename "$0" | sed -e 's/-/ /')
 USAGE="[--quiet] add [-b branch] [--local-branch[=]] [-f|--force] 
[--reference ] [--]  []
or: $dashless [--quiet] status [--cached] [--recursive] [--] [...]
or: $dashless [--quiet] init [--] [...]
-   or: $dashless [--quiet] update [--init] [-N|--no-fetch] [-f|--force] 
[--rebase] [--reference ] [--merge] [--recursive] [--] [...]
+   or: $dashless [--quiet] update [--init] [-N|--no-fetch] [-f|--force] 
[--branch] [--rebase] [--reference ] [--merge] [--recursive] [--] 
[...]
or: $dashless [--quiet] summary [--cached|--files] [--summary-limit ] 
[commit] [--] [...]
or: $dashless [--quiet] foreach [--recursive] 
or: $dashless [--quiet] sync [--] [...]"
@@ -539,6 +539,9 @@ cmd_update()
-f|--force)
force=$1
;;
+   -b|--branch)
+   update="branch"
+   ;;
-r|--rebase)
update="rebase"
;;
@@ -593,6 +596,7 @@ cmd_update()
fi
name=$(module_name "$sm_path") || exit
url=$(git config submodule."$name".url)
+   branch=$(git config submodule."$name".branch)
if ! test -z "$update"
then
update_module=$update
@@ -627,7 +631,7 @@ Maybe you want to use 'update --init'?")"
die "$(eval_gettext "U

[PATCH v4 4/4] Hack fix for 'submodule update does not fetch already present commits'

[W. Trevor King]

From: "W. Trevor King" 

---
 git-submodule.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/git-submodule.sh b/git-submodule.sh
index 28eb4b1..f4a681c 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -640,7 +640,7 @@ Maybe you want to use 'update --init'?")"
subforce="-f"
fi
 
-   if test -z "$nofetch"
+   if test -z "$nofetch" -a "$subsha1" != "$sha1"
then
# Run fetch only if $sha1 isn't present or it
# is not reachable from a ref.
-- 
1.8.0.3.g95edff1.dirty

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 0/4] git-submodule add: Add --local-branch option

[W. Trevor King]

From: "W. Trevor King" 

On Fri, Nov 23, 2012 at 12:54:02PM -0500, W. Trevor King wrote:
> We could add
>
>   $ git submodule update --branch
>
> to checkout the gitlinked SHA1 as submodule..branch in each of
> the submodules, leaving the submodules on the .gitmodules-configured
> branch.  Effectively (for each submodule):
>
>   $ git branch -f $branch $sha1
>   $ git checkout $branch

I haven't gotten any feedback on this as an idea, but perhaps someone
will comment on it as a patch series ;).

Changes since v3:

* --record=… is now --local-branch=…
* Dropped patches 2 ($submodule_ export) and 3 (motivating documentation)
* Added local git-config overrides of .gitmodules' submodule..branch
* Added `submodule update --branch`

Because you need to recurse through submodules for `update --branch`
even if "$subsha1" == "$sha1", I had to amend the conditional
controlling that block.  This broke one of the existing tests, which I
"fixed" in patch 4.  I think a proper fix would involve rewriting

  (clear_local_git_env; cd "$sm_path" &&
   ( (rev=$(git rev-list -n 1 $sha1 --not --all 2>/dev/null) &&
test -z "$rev") || git-fetch)) ||
  die "$(eval_gettext "Unable to fetch in submodule path '\$sm_path'")"

but I'm not familiar enough with rev-list to want to dig into that
yet.  If feedback for the earlier three patches is positive, I'll work
up a clean fix and resubmit.

W. Trevor King (4):
  git-submodule add: Add --local-branch option
  git-submodule init: Record submodule..branch in repository
config.
  git-submodule update: Add --branch option
  Hack fix for 'submodule update does not fetch already present
commits'

 Documentation/config.txt|  9 ++---
 Documentation/git-submodule.txt | 32 -
 Documentation/gitmodules.txt|  5 +++
 git-submodule.sh| 76 +
 t/t7400-submodule-basic.sh  | 43 +++
 t/t7406-submodule-update.sh | 50 ++-
 6 files changed, 187 insertions(+), 28 deletions(-)

-- 
1.8.0.3.g95edff1.dirty

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 2/4] git-submodule init: Record submodule..branch in repository config.

[W. Trevor King]

From: "W. Trevor King" 

This allows users to override the .gitmodules value with a
per-repository value.

Signed-off-by: W. Trevor King 
---
 Documentation/config.txt   |  9 +
 git-submodule.sh   |  7 +++
 t/t7400-submodule-basic.sh | 18 ++
 3 files changed, 30 insertions(+), 4 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 11f320b..1304499 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1994,10 +1994,11 @@ status.submodulesummary::
 submodule..path::
 submodule..url::
 submodule..update::
-   The path within this project, URL, and the updating strategy
-   for a submodule.  These variables are initially populated
-   by 'git submodule init'; edit them to override the
-   URL and other values found in the `.gitmodules` file.  See
+submodule..branch::
+   The path within this project, URL, the updating strategy, and the
+   local branch name for a submodule.  These variables are initially
+   populated by 'git submodule init'; edit them to override the URL and
+   other values found in the `.gitmodules` file.  See
linkgit:git-submodule[1] and linkgit:gitmodules[5] for details.
 
 submodule..fetchRecurseSubmodules::
diff --git a/git-submodule.sh b/git-submodule.sh
index 6eed008..c51b6ae 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -505,6 +505,13 @@ cmd_init()
test -n "$(git config submodule."$name".update)" ||
git config submodule."$name".update "$upd" ||
die "$(eval_gettext "Failed to register update mode for 
submodule path '\$sm_path'")"
+
+   # Copy "branch" setting when it is not set yet
+   branch="$(git config -f .gitmodules submodule."$name".branch)"
+   test -z "$branch" ||
+   test -n "$(git config submodule."$name".branch)" ||
+   git config submodule."$name".branch "$branch" ||
+   die "$(eval_gettext "Failed to register branch for submodule 
path '\$sm_path'")"
done
 }
 
diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
index fc08647..3dc8237 100755
--- a/t/t7400-submodule-basic.sh
+++ b/t/t7400-submodule-basic.sh
@@ -236,6 +236,24 @@ test_expect_success 'submodule add --local-branch= 
--branch' '
)
 '
 
+test_expect_success 'init should register submodule branch in .git/config' '
+   (
+   cd addtest &&
+   git submodule init &&
+   test "$(git config submodule.submod-follow.branch)" = "final"
+   )
+'
+
+test_expect_success 'local config should override .gitmodules branch' '
+   (
+   cd addtest &&
+   rm -fr submod-follow &&
+   git config submodule.submod-follow.branch initial
+   git submodule init &&
+   test "$(git config submodule.submod-follow.branch)" = "initial"
+   )
+'
+
 test_expect_success 'setup - add an example entry to .gitmodules' '
GIT_CONFIG=.gitmodules \
git config submodule.example.url git://example.com/init.git
-- 
1.8.0.3.g95edff1.dirty

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 1/4] git-submodule add: Add --local-branch option

[W. Trevor King]

From: "W. Trevor King" 

This option allows you to record a submodule..branch option in
.gitmodules.  Git does not currently use this configuration option for
anything, but users have used it for several things, so it makes sense
to add some syntactic sugar for initializing the value.

Current consumers:

Ævar uses this setting to designate the local branch to checkout when
pulling submodule updates:

  $ git submodule foreach 'git checkout $(git config --file 
$toplevel/.gitmodules submodule.$name.branch) && git pull'

as he describes in

  commit f030c96d8643fa0a1a9b2bd9c2f36a77721fb61f
  Author: Ævar Arnfjörð Bjarmason 
  Date:   Fri May 21 16:10:10 2010 +

git-submodule foreach: Add $toplevel variable

Gerrit uses the same interpretation for the setting, but because
Gerrit has direct access to the subproject repositories, it updates
the superproject repositories automatically when a subproject changes.
Gerrit also accepts the special value '.', which it expands into the
superproject's branch name.

Earlier version of this patch remained agnostic on the variable usage,
but this was deemed potentially confusing.  Future patches in this
series will extend the submodule command to use the stored value
internally.

[1] 
https://gerrit.googlesource.com/gerrit/+/master/Documentation/user-submodules.txt

Signed-off-by: W. Trevor King 
---
 Documentation/git-submodule.txt | 12 ++--
 Documentation/gitmodules.txt|  5 +
 git-submodule.sh| 19 ++-
 t/t7400-submodule-basic.sh  | 25 +
 4 files changed, 58 insertions(+), 3 deletions(-)

diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index b4683bb..d0b4436 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -9,8 +9,8 @@ git-submodule - Initialize, update or inspect submodules
 SYNOPSIS
 
 [verse]
-'git submodule' [--quiet] add [-b branch] [-f|--force]
- [--reference ] [--]  []
+'git submodule' [--quiet] add [-b branch] [--local-branch[=]]
+ [-f|--force] [--reference ] [--]  []
 'git submodule' [--quiet] status [--cached] [--recursive] [--] [...]
 'git submodule' [--quiet] init [--] [...]
 'git submodule' [--quiet] update [--init] [-N|--no-fetch] [--rebase]
@@ -209,6 +209,14 @@ OPTIONS
 --branch::
Branch of repository to add as submodule.
 
+--local-branch::
+   Record a branch name used as `submodule..branch` in
+   `.gitmodules` for future reference.  If you do not list an explicit
+   name here, the name given with `--branch` will be recorded.  If that
+   is not set either, `HEAD` will be recorded.  Because the branch name
+   is optional, you must use the equal-sign form
+   (`--local-branch=`), not `--local-branch `.
+
 -f::
 --force::
This option is only valid for add and update commands.
diff --git a/Documentation/gitmodules.txt b/Documentation/gitmodules.txt
index 4effd78..840ccfe 100644
--- a/Documentation/gitmodules.txt
+++ b/Documentation/gitmodules.txt
@@ -47,6 +47,11 @@ submodule..update::
This config option is overridden if 'git submodule update' is given
the '--merge', '--rebase' or '--checkout' options.
 
+submodule..branch::
+   A local branch name for the submodule (to avoid headless operation).
+   Set with the "--local-branch" option to "git submodule add", or
+   directly using "git config".
+
 submodule..fetchRecurseSubmodules::
This option can be used to control recursive fetching of this
submodule. If this option is also present in the submodules entry in
diff --git a/git-submodule.sh b/git-submodule.sh
index ab6b110..6eed008 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -5,7 +5,7 @@
 # Copyright (c) 2007 Lars Hjemli
 
 dashless=$(basename "$0" | sed -e 's/-/ /')
-USAGE="[--quiet] add [-b branch] [-f|--force] [--reference ] [--] 
 []
+USAGE="[--quiet] add [-b branch] [--local-branch[=]] [-f|--force] 
[--reference ] [--]  []
or: $dashless [--quiet] status [--cached] [--recursive] [--] [...]
or: $dashless [--quiet] init [--] [...]
or: $dashless [--quiet] update [--init] [-N|--no-fetch] [-f|--force] 
[--rebase] [--reference ] [--merge] [--recursive] [--] [...]
@@ -20,6 +20,8 @@ require_work_tree
 
 command=
 branch=
+local_branch=
+local_branch_empty=
 force=
 reference=
 cached=
@@ -257,6 +259,12 @@ cmd_add()
branch=$2
shift
;;
+   --local-branch)
+   local_branch_empty=true
+   ;;
+   --local-branch=*)
+   local_branch="${1#*=}"
+   ;;
-f | --force)
force=$1
;;
@@ -328,6 +336,11 @@ cmd_add()
git ls-files --error-unmatch "$sm_path" > /dev/null 2>&1 &&
die "$(eval_gettext "'\$sm_path' already exists in the index")"

Re: git bundle format

[Stephen Bash]

- Original Message -
> From: "Jason J CTR Pyeron (US)" 
> Sent: Monday, November 26, 2012 2:24:54 PM
> Subject: git bundle format
> 
> I am facing a situation where I would like to use git bundle but at
> the same time inspect the contents to prevent a spillage[1].

As someone who faced a similar situation in a previous life, I'll offer my 
$0.02, but I'm certainly not the technical expert here.

> Given we have a public repository which was cloned on to a secret
> development repository. Now the developers do some work which should
> not be sensitive in any way and commit and push it to the secret
> repository.
> 
> Now they want to release it out to the public. The current process is
> to review the text files to ensure that there is no "secret" sauce
> in there and then approve its release. This current process ignores
> the change tracking and all non-content is lost.
> 
> In this situation we should assume that the bundle does not have any
> content which is already in the public repository, that is it has
> the minimum data to make it pass a git bundle verify from the public
> repositories point of view. We would then take the bundle and pipe
> it though the "git-bundle2text" program which would result in a
> "human" inspectable format as opposed to the packed format[2]. The
> security reviewer would then see all the information being released
> and with the help of the public repository see how the data changes
> the repository.
> 
> Am I barking up the right tree?

First, a shot out of left field: how about a patch based workflow? (similar to 
the mailing list, just replace email with sneakernet)  Patches are plain text 
and simple to review (preferable to an "opaque" binary format?).

Second, thinking about your proposed bundle-based workflow I have two questions 
I'd have to answer to be comfortable with the solution:

  1) Does the binary bundle contain any sensitive information?
  2) Do the diffs applied to public repo contain any sensitive data?

Question 1 seems tricky to someone who knows *nothing* about the bundle format 
(e.g. me).  Maybe some form of bundle2text can be vetted enough that everyone 
involved believes that there is no other information traveling with the bundle 
(if so, you're golden).  Here I have to trust other experts.  On the flip side, 
even if the bundle itself is polluted (or considered to be lacking proof to the 
contrary), if (2) is considered safe, the patching of the public repo could 
potentially be done on a sacrificial hard drive before pushing.

Question 2 is relatively straight forward and lead me to the patch idea.  I 
would:
  - Bundle the public repository
  - Init a new repo in the secure space from the public bundle
  - Fetch from the to-be-sanitized bundle into the new repo
  - Examine commits (diffs) introduced by branches in the to-be-sanitized bundle
  - Perhaps get a list of all the objects in the to-be-sanitized bundle and do 
a git-cat-file on each of them (if the bundle is assembled correctly it 
shouldn't have any unreachable objects...).  This step may be extraneous after 
the previous.

HTH,
Stephen
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git bundle format

[Felipe Contreras]

On Mon, Nov 26, 2012 at 9:50 PM, Pyeron, Jason J CTR (US)
 wrote:
>> -Original Message-
>> From: Felipe Contreras
>> Sent: Monday, November 26, 2012 3:20 PM
>>
>> On Mon, Nov 26, 2012 at 8:24 PM, Pyeron, Jason J CTR (US)
>>  wrote:
>> > I may need to be nudged in a better direction, but please try to
>> understand my intentions.
>> >
>> > I am facing a situation where I would like to use git bundle but at
>> the same time inspect the contents to prevent a spillage[1].
>> >
> 
>> >
>> > Am I barking up the right tree?
>>
>> Have you tried 'git fast-export'? The output is definitely not human
>> inspectable, but should be relatively easy to parse to generate such a
>> format. And instead of 'git bundle unbundle' you could use 'git
>> fast-import'. or simply do the conversion in your script.
>
> No. But I am going to read up on it today. It clearly says "You can use it as 
> a human-readable bundle replacement"[4].

Ah, didn't notice that.

> My initial question is does it ever use deltas?

No.

> The repositories I just tested it on only seem to output full blobs (which is 
> really nice from this use case point of view).

In my experience it's nice for most use-cases. Since git only deals
with full file contents, that makes sense.

Cheers.

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git-gui: textconv not used on unstaged files

[Junio C Hamano]

Peter Oberndorfer  writes:

> Does anybody have a idea which git command would output the diff
> of a untracked file against /dev/null?

The "--no-index" option is meant as a bolt-on to let you use various
features of "git diff" that is missing from other people's "diff" in
a context where git does not know anything about that file.  It
should be usable even outside a git repository.

$ git diff --no-index /dev/null new-file.txt

I do not know offhand (and didn't bother to check) if textconv
applies, though.  It does need access to a git repository as it
reads from the $GIT_DIR/config to learn what to do.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: git bundle format

[Pyeron, Jason J CTR (US)]

> -Original Message-
> From: Junio C Hamano
> Sent: Monday, November 26, 2012 3:38 PM
> 
> "Pyeron, Jason J CTR (US)" writes:
> 
> > In this situation we should assume that the bundle does not have
> > any content which is already in the public repository, that is it
> > has the minimum data to make it pass a git bundle verify from the
> > public repositories point of view. We would then take the bundle
> > and pipe it though the "git-bundle2text" program which would
> > result in a "human" inspectable format as opposed to the packed
> > format[2]. The security reviewer would then see all the
> > information being released and with the 

*** Assumed that the inspector had a copy of the original public repo

> > help of the public
> > repository see how the data changes the repository.



> 
> The bundle file is a thinly wrapped packfile, with extra information
> that tells what objects in the bundle are the tips of histories and
> what objects the repository the bundle gets unbundled has to have.
> So your "git-bundle2text" would likely to involve fetching from the
> bundle and inspecting the resulting history and the working tree
> files.

Yea, I knew the inspection tool was going to get messy.

-Jason


smime.p7s
Description: S/MIME cryptographic signature

RE: git bundle format

[Pyeron, Jason J CTR (US)]

> -Original Message-
> From: Felipe Contreras
> Sent: Monday, November 26, 2012 3:20 PM
> 
> On Mon, Nov 26, 2012 at 8:24 PM, Pyeron, Jason J CTR (US)
>  wrote:
> > I may need to be nudged in a better direction, but please try to
> understand my intentions.
> >
> > I am facing a situation where I would like to use git bundle but at
> the same time inspect the contents to prevent a spillage[1].
> >

> >
> > Am I barking up the right tree?
> 
> Have you tried 'git fast-export'? The output is definitely not human
> inspectable, but should be relatively easy to parse to generate such a
> format. And instead of 'git bundle unbundle' you could use 'git
> fast-import'. or simply do the conversion in your script.

No. But I am going to read up on it today. It clearly says "You can use it as a 
human-readable bundle replacement"[4]. My initial question is does it ever use 
deltas? The repositories I just tested it on only seem to output full blobs 
(which is really nice from this use case point of view).

-Jason


4: http://www.kernel.org/pub/software/scm/git/docs/git-fast-export.html


smime.p7s
Description: S/MIME cryptographic signature

Re: [PATCH] fast-export: Allow pruned-references in mark file

[Junio C Hamano]

Antoine Pelisse  writes:

>> I am not sure I follow the above, but anyway, I think the patch does
>> is safe because (1) future "fast-export" will not refer to these
>> pruned objects in its output (we have decided that these pruned
>> objects are not used anywhere in the history so nobody will refer to
>> them) and (2) we still need to increment the id number so that later
>> objects in the marks file get assigned the same id number as they
>> were assigned originally (otherwise we will not name these objects
>> consistently when we later talk about them).
>
> I fully agree on (1), not so much on (2) though.
> ...
> Both "commit mark :2" and "commit mark :3" end up being marked :2.
> Any tool like git-remote-hg that is using a mapping from mark <-> hg changeset
> could then fail.

Yeah, I think I agree that you would need to make sure that the
other side does not use the revision marked with :2, once you retire
the object you originally marked with :2 by pruning.  Shouldn't the
second export show :1 and :3 but not :2?  It feels like a bug in the
exporter to me that the mark number is reused in such a case.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] fast-export: Allow pruned-references in mark file

[Felipe Contreras]

On Mon, Nov 26, 2012 at 9:04 PM, Antoine Pelisse  wrote:
>> I am not sure I follow the above, but anyway, I think the patch does
>> is safe because (1) future "fast-export" will not refer to these
>> pruned objects in its output (we have decided that these pruned
>> objects are not used anywhere in the history so nobody will refer to
>> them) and (2) we still need to increment the id number so that later
>> objects in the marks file get assigned the same id number as they
>> were assigned originally (otherwise we will not name these objects
>> consistently when we later talk about them).
>
> I fully agree on (1), not so much on (2) though.
>
> I have the following behavior using my patch and running that script
> that doesn't look correct.
>
> echo "Working scenario"
> git init test &&
> (cd test &&
> git commit --allow-empty -m "Commit mark :1" &&
> git commit --allow-empty -m "Commit mark :2" &&
> git fast-export --export-marks=MARKS master > /dev/null &&
> cat MARKS &&
> git reset HEAD~1 &&
> sleep 1 &&
> git reflog expire --all --expire=now &&
> git prune --expire=now &&
> git commit --allow-empty -m "Commit mark :3" &&
> git fast-export --import-marks=MARKS \
>   --export-marks=MARKS master > /dev/null &&
> cat MARKS) &&
> rm -rf test
>
> echo "Non-working scenario"
> git init test &&
> (cd test &&
> git commit --allow-empty -m "Commit mark :1" &&
> git commit --allow-empty -m "Commit mark :2" &&
> git fast-export --export-marks=MARKS master > /dev/null &&
> cat MARKS &&
> git reset HEAD~1 &&
> sleep 1 &&
> git reflog expire --all --expire=now &&
> git prune --expire=now &&
> git fast-export --import-marks=MARKS \
>   --export-marks=MARKS master > /dev/null &&
> git commit --allow-empty -m "Commit mark :3" &&
> git fast-export --import-marks=MARKS \
>   --export-marks=MARKS master > /dev/null &&
> cat MARKS) &&
> rm -rf test
>
> outputs something like this:
> Working scenario
> Initialized empty Git repository in /home/antoine/test/.git/
> [master (root-commit) 6cf350d] Commit mark :1
> [master 8f97f85] Commit mark :2
> :1 6cf350d7ecb3dc6573b00f839a6a51625ed28966
> :2 8f97f85e1e7badf6a3daf411cf8d1133b00d522e
> [master 21cadfd] Commit mark :3
> warning: Could not read blob 8f97f85e1e7badf6a3daf411cf8d1133b00d522e
> :1 6cf350d7ecb3dc6573b00f839a6a51625ed28966
> :3 21cadfd87d90c05ce8770c968e5ed3d072ead4ae
> Non-working scenario
> Initialized empty Git repository in /home/antoine/test/.git/
> [master (root-commit) 5b5f7ec] Commit mark :1
> [master b224390] Commit mark :2
> :2 b224390daee199644495c15503882eb84df07df5
> :1 5b5f7ec77768393aab2a0c2c11b4b8f7773f8678
> warning: Could not read blob b224390daee199644495c15503882eb84df07df5
> [master 181a774] Commit mark :3
> :1 5b5f7ec77768393aab2a0c2c11b4b8f7773f8678
> :2 181a7744c6d3428edb01a1adc9df247e9620be5f
>
> Both "commit mark :2" and "commit mark :3" end up being marked :2.
> Any tool like git-remote-hg that is using a mapping from mark <-> hg changeset
> could then fail.

I don't understand. "commit mark :2" 'git fast-export' would never
point to that object again, the new commit would override that mark:

commit refs/heads/master
mark :2
...
commit mark :3

Then 'git remote-hg' should override that mark as well.

But it doesn't matter, because that would be the case only for the
last object, as soon as you find another valid object, that object's
mark will be considered the last one.

And what Junio said is consistent with what you want: last_idnum
should be updated even if the object is not valid.

Cheers.

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git bundle format

[Junio C Hamano]

"Pyeron, Jason J CTR (US)"  writes:

> In this situation we should assume that the bundle does not have
> any content which is already in the public repository, that is it
> has the minimum data to make it pass a git bundle verify from the
> public repositories point of view. We would then take the bundle
> and pipe it though the "git-bundle2text" program which would
> result in a "human" inspectable format as opposed to the packed
> format[2]. The security reviewer would then see all the
> information being released and with the help of the public
> repository see how the data changes the repository.

The bundle file is a thinly wrapped packfile, with extra information
that tells what objects in the bundle are the tips of histories and
what objects the repository the bundle gets unbundled has to have.
So your "git-bundle2text" would likely to involve fetching from the
bundle and inspecting the resulting history and the working tree
files.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Ignoring boring lines(that do not contain information) in git diff

[Peter Oberndorfer]

On 2012-10-08 18:44, Peter Oberndorfer wrote:
> Hi,
>
> is there a way to tell git diff about lines that are uninteresting?
> I mean lines which do not contain a lot of information and
> appear several times in pre and post image.
>
> For example whitespace or language dependent stuff like.
> {
> }
> END_IF;
> END_FOR;
> end sub
>
> I have seen diffs that containing 2 interesting hunks splitted by such boring 
> lines.
> (I have attached a anonymized version of a real world example where this 
> happens)
>
> I think the diff would be clearer when this boring line was added to the 
> surrounding hunks.
> I already tried patience diff but in my test case it changed nothing.
> I am using git 1.7.10.
>

Hi,

does anybody have a idea if this is possible?
Or some comments if they would find such a feature useful?

Greetings Peter


example_diff_boring_split.diff

diff --git a/Source/Frobble/Blabber.txt b/Source/Frobble/Blabber.txt
index 87ccddb..627bc3e 100644
--- a/Source/Frobble/Blabber.txt
+++ b/Source/Frobble/Blabber.txt
@@ -138,73 +138,74 @@ END_VAR
- //frobble immediately if immediately flag is set
- IF bImmediately AND NOT Array[i].bDisabled THEN
-aFrobble(i, Entry);
+ IF Entry.bBlah THEN
+   Alarm.Alarm  := SomeAlarm;
+ ELSE
+   Alarm := Entry;
  END_IF;
- // signal if frobble count has changed
- iChanged := iChanged + 1;
- EXIT;
+ IF Array[i].Alarm = Alarm THEN
+//do not brabble if alarm is gobbled
+   EXIT;
+ END_IF;
   END_IF;
-   END_FOR;
-ELSE
-   aExample(Name := 'aaa',
-ID1 := 1);
-END_IF;
+   ELSE
+  //entry not found, adding
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git-gui: textconv not used on unstaged files

[Peter Oberndorfer]

On 2012-10-24 20:33, Peter Oberndorfer wrote:
> Hi,
>
> i am using a textconv filter to display .doc files as plain text.
> It seems git gui does not use this textconv filter for displaying new 
> unstaged files
> (other files? = _O)
> It seems diff.tcl start_show_diff calls show_other_diff because of this.
> This manually loads the file and does not care about textconv filters.
>
> Is this manual loading really necessary or can't we just ask git?
> If it is can it be modified to use the textconv filter?
>
Does anybody have a idea which git command
would output the diff of a untracked file against /dev/null?
So I can show the textconved version of the file in git gui.
(and not reinvent the code to apply textconv already in git)

Thanks,
Greetings Peter

>
> .gitattributes:
> *.docdiff=astextplain
>
> gitconfig:
> [diff "astextplain"]
> textconv = astextplain

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: gitpacker progress report and a question

[Felipe Contreras]

On Thu, Nov 15, 2012 at 10:28 PM, Eric S. Raymond  wrote:
> Some days ago I reported that I was attempting to write a tool that could
> (a) take a git repo and unpack it into a tarball sequence plus a metadata log,
> (b) reverse that operation, packing a tarball and log sequence into a repo.
>
> Thanks in part to advice by Andreas Schwab and in part to looking at the
> text of the p4 import script, this effort has succeeded.  A proof of
> concept is enclosed.  It isn't documented yet, and has not been tested
> on a repository with branches or merges in the history, but I am confident
> that the distance from here to a finished and tested tool is short.
>
> The immediate intended use is for importing older projects that are
> available only as sequences of release tarballs, but there are other
> sorts of repository surgery that would become easier using it.
>
> I'm still looking for a better name for it and would welcome suggestions.
>
> Before I do much further work, I need to determine how this will be shipped.
> I see two possibilities: either I ship it as a small standalone project,
> or it becomes a git subcommand shipped with the git suite. How I document
> it and set up its tests would differ between these two cases.

Please look at Documentation/SubmittingPatches, you should send
patches in inline format, preferably with 'git format-patch -M', and
preferably with 'git send-email' (in which case you don't need
format-patch), otherwise people will have trouble reviewing, or miss
it completely (as it was the case for me).

I have many comments, but I'll wait until you send the patch inlined,
I'll just address these:

1) I tried it, and it doesn't seem to import (pack?) are repository
with sub-directories in it

2) Using 'git fast-import' is probably simpler, and more efficient

Here is a proof of concept I wrote in ruby that is half the size, and
seems to implement the same functionality. The format is exactly the
same, but I think it should be modified to be more efficient.

Cheers.

>From eb3c34699d7f5d4eec4f088344659b8d9b6a07ea Mon Sep 17 00:00:00 2001
From: Felipe Contreras 
Date: Mon, 26 Nov 2012 20:48:38 +0100
Subject: [PATCH] Add new git-weave tool

Signed-off-by: Felipe Contreras 
---
 contrib/weave/git-weave | 166 
 1 file changed, 166 insertions(+)
 create mode 100755 contrib/weave/git-weave

diff --git a/contrib/weave/git-weave b/contrib/weave/git-weave
new file mode 100755
index 000..3106121
--- /dev/null
+++ b/contrib/weave/git-weave
@@ -0,0 +1,166 @@
+#!/usr/bin/env ruby
+
+require 'optparse'
+require 'find'
+require 'fileutils'
+
+def export(indir = '.', out = STDOUT)
+  open(File.join(indir, 'log')).each("\n.\n") do |data|
+
+@msg = nil
+@parents = []
+
+data.chomp(".\n").each_line do |l|
+  if not @msg
+case l
+when /^commit (.+)$/
+  @id = $1
+when /^author (.+)$/
+  @author = $1
+when /^committer (.+)$/
+  @committer = $1
+when /^parent (.+)$/
+  @parents << $1
+when /^$/
+  @msg = ""
+end
+  else
+@msg << l
+  end
+end
+
+out.puts "commit refs/heads/master"
+out.puts "mark :#{@id}"
+out.puts "author #{@author}"
+out.puts "committer #{@committer}"
+out.puts "data #{@msg.bytesize}"
+out.puts @msg
+
+@parents.each_with_index do |p, i|
+  if i == 0
+out.puts "from :%u" % p
+  else
+out.puts "merge :%u" % p
+  end
+end
+
+# files
+out.puts 'deleteall'
+FileUtils.cd(File.join(indir, @id)) 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)
+mode = File.executable?(e) ? '100755' : '100644'
+if File.symlink?(e)
+  mode = '12'
+  content = File.readlink(e)
+end
+out.puts 'M %s inline %s' % [mode, filename]
+out.puts "data #{content.bytesize}"
+out.puts content
+  end
+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, '--all', '--reverse']
+  commits = {}
+
+  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
+
+out.puts "commit #{num}"
+@parents.each do |p|
+  out.puts "parent #{commits[p]}"

Re: [PATCH] fast-export: Allow pruned-references in mark file

[Antoine Pelisse]

> I am not sure I follow the above, but anyway, I think the patch does
> is safe because (1) future "fast-export" will not refer to these
> pruned objects in its output (we have decided that these pruned
> objects are not used anywhere in the history so nobody will refer to
> them) and (2) we still need to increment the id number so that later
> objects in the marks file get assigned the same id number as they
> were assigned originally (otherwise we will not name these objects
> consistently when we later talk about them).

I fully agree on (1), not so much on (2) though.

I have the following behavior using my patch and running that script
that doesn't look correct.

echo "Working scenario"
git init test &&
(cd test &&
git commit --allow-empty -m "Commit mark :1" &&
git commit --allow-empty -m "Commit mark :2" &&
git fast-export --export-marks=MARKS master > /dev/null &&
cat MARKS &&
git reset HEAD~1 &&
sleep 1 &&
git reflog expire --all --expire=now &&
git prune --expire=now &&
git commit --allow-empty -m "Commit mark :3" &&
git fast-export --import-marks=MARKS \
  --export-marks=MARKS master > /dev/null &&
cat MARKS) &&
rm -rf test

echo "Non-working scenario"
git init test &&
(cd test &&
git commit --allow-empty -m "Commit mark :1" &&
git commit --allow-empty -m "Commit mark :2" &&
git fast-export --export-marks=MARKS master > /dev/null &&
cat MARKS &&
git reset HEAD~1 &&
sleep 1 &&
git reflog expire --all --expire=now &&
git prune --expire=now &&
git fast-export --import-marks=MARKS \
  --export-marks=MARKS master > /dev/null &&
git commit --allow-empty -m "Commit mark :3" &&
git fast-export --import-marks=MARKS \
  --export-marks=MARKS master > /dev/null &&
cat MARKS) &&
rm -rf test

outputs something like this:
Working scenario
Initialized empty Git repository in /home/antoine/test/.git/
[master (root-commit) 6cf350d] Commit mark :1
[master 8f97f85] Commit mark :2
:1 6cf350d7ecb3dc6573b00f839a6a51625ed28966
:2 8f97f85e1e7badf6a3daf411cf8d1133b00d522e
[master 21cadfd] Commit mark :3
warning: Could not read blob 8f97f85e1e7badf6a3daf411cf8d1133b00d522e
:1 6cf350d7ecb3dc6573b00f839a6a51625ed28966
:3 21cadfd87d90c05ce8770c968e5ed3d072ead4ae
Non-working scenario
Initialized empty Git repository in /home/antoine/test/.git/
[master (root-commit) 5b5f7ec] Commit mark :1
[master b224390] Commit mark :2
:2 b224390daee199644495c15503882eb84df07df5
:1 5b5f7ec77768393aab2a0c2c11b4b8f7773f8678
warning: Could not read blob b224390daee199644495c15503882eb84df07df5
[master 181a774] Commit mark :3
:1 5b5f7ec77768393aab2a0c2c11b4b8f7773f8678
:2 181a7744c6d3428edb01a1adc9df247e9620be5f

Both "commit mark :2" and "commit mark :3" end up being marked :2.
Any tool like git-remote-hg that is using a mapping from mark <-> hg changeset
could then fail.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Third try at documenting command integration requirements.

[Junio C Hamano]

e...@thyrsus.com (Eric S. Raymond) writes:

> This document contains no new policies or proposals; it attempts
> to document established practices and interface requirements.
>
> Signed-off-by: Eric S. Raymond 

I'll reword the title (readers of "git log" output 6 months down the
road will not care if this is the third try or the first one) and
tweak things here and there before queuing.

> diff --git a/Documentation/technical/api-command.txt 
> b/Documentation/technical/api-command.txt
> new file mode 100644
> index 000..c1c1afb
> --- /dev/null
> +++ b/Documentation/technical/api-command.txt
> @@ -0,0 +1,91 @@
> += Integrating new subcommands =
> +
> +This is how-to documentation for people who want to add extension
> +commands to git.  It should be read alongside api-builtin.txt.
> +
> +== Runtime environment ==
> +
> +git subcommands are standalone executables that live in the git
> +execution directory, normally /usr/lib/git-core.  The git executable itself
> +is a thin wrapper that sets GIT_DIR and passes command-line arguments
> +to the subcommand.

$ echo >$HOME/bin/git-showenv '#!/bin/sh
exec env'
$ chmod +x $HOME/bin/git-showenv
$ git showenv | grep GIT_

gives me emptyness.  I rewrote the above to:

git subcommands are standalone executables that live in the git exec
path, normally /usr/lib/git-core.  The git executable itself is a
thin wrapper that knows where the subcommands live, and runs them by
passing command-line arguments to them.

FYI, a builtin command _can_ ask the git wrapper to set up the
execution environment by setting RUN_SETUP bit in its cmd_struct
entry, but it is not done by default.

> +== Implementation languages ==
> +
> +Most subcommands are written in C or shell.  A few are written in
> +Perl.  A tiny minority are written in Python.
> +
> +While we strongly encourage coding in portable C for portability, these
> +specific scripting languages are also acceptable. We won't accept more
> +without a very strong technical case, as we don't want to broaden the
> +git suite's required dependencies.
> +
> +Python is fine for import utilities, surgical tools, remote helpers
> +and other code at the edges of the git suite - but it should not yet
> +be used for core functions. This may change in the future; the problem
> +is that we need better Python integration in the git Windows installer
> +before we can be confident people in that environment won't
> +experience an unacceptably large loss of capability.

As Felipe and others said in the discussion, Python is not *that*
special over other languages (and I think we have a Go in contrib/).

I rewrote the above to:

Most subcommands are written in C or shell.  A few are written in
Perl.

While we strongly encourage coding in portable C for portability,
these specific scripting languages are also acceptable.  We won't
accept more without a very strong technical case, as we don't want
to broaden the git suite's required dependencies.  Import utilities,
surgical tools, remote helpers and other code at the edges of the
git suite are more lenient and we allow Python (and even Tcl/tk),
but they should not be used for core functions.

This may change in the future.  Especially Python is not allowed in
core because we need better Python integration in the git Windows
installer before we can be confident people in that environment
won't experience an unacceptably large loss of capability.

> +C commands are normally written as single modules, named after the
> +command, that link a collection of functions called libgit.  Thus,
> +your command 'git-foo' would normally be implemented as a single
> +"git-foo.c"; this organization makes it easy for people reading the

"git-foo.c" (or "builtin/foo.c" if it is to be linked to the main
binary);

> +4. If your command has any dependency on a a particular version of
> +your language, document it in the INSTALL file.

s/a a/a/;

> +6. When your patch is merged, remind the maintainer to add something
> +about it in the RelNotes file.

6. Give the maintainer a one paragraph to include in the RelNotes
file to describe the new feature; a good place to do so is in the
cover letter [PATCH 0/n].

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3] send-email: avoid questions when user has an ident

[Junio C Hamano]

Felipe Contreras  writes:

> 3) Full name + fqdm
>
>   Who should the emails appear to be from?
>   [Felipe Contreras ]
> ...
> This is bad, because we will try with an address such as
> 'feli...@nysa.felipec.org', which is most likely not what the user
> wants, but the user will get warned by default (confirm=auto), and
> if not, most likely the sending won't work, which the user would
> readily note and fix.

OK, sounds sensible.

> Changes since v2:
>
>  * Merge the relevant tests by Jeff King (the rest of the tests might be
>useful, but they belong in a separate patch series)

Thanks. Queued.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: git bundle format

[Pyeron, Jason J CTR (US)]

Left off a citation to an old thread.

> -Original Message-
> From: Pyeron, Jason J CTR (US)
> Sent: Monday, November 26, 2012 2:25 PM
> 
> I may need to be nudged in a better direction, but please try to
> understand my intentions.
> 
> I am facing a situation where I would like to use git bundle but at the
> same time inspect the contents to prevent a spillage[1].
> 
> Given we have a public repository which was cloned on to a secret
> development repository. Now the developers do some work which should
> not be sensitive in any way and commit and push it to the secret
> repository.
> 
> Now they want to release it out to the public. The current process is
> to review the text files to ensure that there is no "secret" sauce in
> there and then approve its release. This current process ignores the
> change tracking and all non-content is lost.
> 
> 
> In this situation we should assume that the bundle does not have any
> content which is already in the public repository, that is it has the
> minimum data to make it pass a git bundle verify from the public
> repositories point of view. We would then take the bundle and pipe it
> though the "git-bundle2text" program which would result in a "human"
> inspectable format
[3]
> as opposed to the packed format[2]. The security
> reviewer would then see all the information being released and with the
> help of the public repository see how the data changes the repository.
> 
> Am I barking up the right tree?
> 
> 
> 1: http://en.wikipedia.org/wiki/Spillage_of_Classified_Information
> 2: http://git-scm.com/book/ch9-4.html
3: 
http://git.661346.n2.nabble.com/How-to-extract-files-out-of-a-quot-git-bundle-quot-no-matter-what-td1679188.html


smime.p7s
Description: S/MIME cryptographic signature

git bundle format

[Pyeron, Jason J CTR (US)]

I may need to be nudged in a better direction, but please try to understand my 
intentions.

I am facing a situation where I would like to use git bundle but at the same 
time inspect the contents to prevent a spillage[1].

Given we have a public repository which was cloned on to a secret development 
repository. Now the developers do some work which should not be sensitive in 
any way and commit and push it to the secret repository.

Now they want to release it out to the public. The current process is to review 
the text files to ensure that there is no "secret" sauce in there and then 
approve its release. This current process ignores the change tracking and all 
non-content is lost.


In this situation we should assume that the bundle does not have any content 
which is already in the public repository, that is it has the minimum data to 
make it pass a git bundle verify from the public repositories point of view. We 
would then take the bundle and pipe it though the "git-bundle2text" program 
which would result in a "human" inspectable format as opposed to the packed 
format[2]. The security reviewer would then see all the information being 
released and with the help of the public repository see how the data changes 
the repository.

Am I barking up the right tree?


1: http://en.wikipedia.org/wiki/Spillage_of_Classified_Information
2: http://git-scm.com/book/ch9-4.html



smime.p7s
Description: S/MIME cryptographic signature

[PATCH] Fix typo in remote set-head usage

[Antoine Pelisse]

parenthesis are not matching in `builtin_remote_sethead_usage`
as a square bracket is closing something never opened.

Signed-off-by: Antoine Pelisse 
---
 builtin/remote.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/builtin/remote.c b/builtin/remote.c
index a5a4b23..937484d 100644
--- a/builtin/remote.c
+++ b/builtin/remote.c
@@ -39,7 +39,7 @@ static const char * const builtin_remote_rm_usage[] = {
 };
 
 static const char * const builtin_remote_sethead_usage[] = {
-   N_("git remote set-head  (-a | -d | ])"),
+   N_("git remote set-head  (-a | -d | )"),
NULL
 };
 
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 5/7] push: require force for refs under refs/tags/

[Junio C Hamano]

Chris Rorvick  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.

The updated logic in the patch looks sensible.  Thanks.

> ...
> +test_expect_success 'push requires --force to update lightweight tag' '
> + mk_test heads/master &&
> + mk_child child1 &&
> + mk_child child2 &&
> + (
> + cd child1 &&
> + git tag Tag &&
> + git push ../child2 Tag &&
> + git push ../child2 Tag &&
> + >file1 &&
> + git add file1 &&
> + git commit -m "file1" &&
> + git tag -f Tag &&
> + test_must_fail git push ../child2 Tag &&
> + git push --force ../child2 Tag &&
> + git tag -f Tag &&
> + test_must_fail git push ../child2 Tag HEAD~ &&
> + git push --force ../child2 Tag
> + )
> +'
> +
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 7/7] push: clarify rejection of update to non-commit-ish

[Junio C Hamano]

Chris Rorvick  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 
> ---
>  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.

With this code, the old must be a commit but new can be a tag that
points at a commit?  Why?

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/7] push: return reject reasons via a mask

[Junio C Hamano]

Chris Rorvick  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 
> ---

Thanks for a reroll.

I do not think they are "masks", by the way.  They are set of flags
(i.e. a bitset).

A bitset is often called "a mask" when it is used to "mask" a subset
of bits in another bitset that has the real information, either to
ignore irrelevant bits or to pick only the relevant bits from the
latter.  And your "reject_mask" is never used as a mask in this
patch---it is the bitset that has the real information and it gets
masked by constant masks like REJECT_NON_FF_HEAD.

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, and because this is to record the reasons why
the push was rejected, "rejection_reason" might be a better name for
it.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] makefile: hide stderr of curl-config test

[Junio C Hamano]

Paul Gortmaker  writes:

> Currently, if you don't have curl installed, you will get
>
> $ make distclean 2>&1 | grep curl
> /bin/sh: curl-config: not found
> /bin/sh: curl-config: not found
> /bin/sh: curl-config: not found
> /bin/sh: curl-config: not found
> /bin/sh: curl-config: not found
> $
>
> The intent is not to alarm the user, but just to test if there is
> a new enough curl installed.  However, if you look at search engine
> suggested completions, the above "error" messages are confusing
> people into thinking curl is a hard requirement.

Good observation and identification of an issue to tackle.  But why
isn't the patch like this?

PROGRAMS += $(REMOTE_CURL_NAMES)
-   curl_check := $(shell (echo 070908; curl-config --vernum) | sort -r | 
sed -ne 2p)
+   curl_check := $(shell (echo 070908; curl-config --vernum) 2>/dev/null | 
sort -r | sed -ne 2p)
ifeq "$(curl_check)" "070908"

Removal of the "reject old libcURL" is logically a separate thing
regardless of the "alarming output from make", and it probably is
better done as a separate step in a two-patch series.  Doing things
that way, when somebody objects to this:

> It wants to ensure curl is newer than 070908.  The oldest
> machine I could find (RHEL 4.6) is 2007 vintage according
> to /proc/version data, and it has curl 070C01.

saying that their installation still cares about older libcURL, we
can still keep the "remove alarming output from make" bit.

>
> The failure here is to mask stderr in the test.  However, since
> the chance of curl being installed, but too old is essentially
> nil, lets just check for existence and drop the ancient version
> threshold check, if for no other reason, than to simplifly the
> parsing of what the makefile is trying to do by humans.
>
> Signed-off-by: Paul Gortmaker 
>
> diff --git a/Makefile b/Makefile
> index 9bc5e40..56f55f6 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1573,8 +1573,8 @@ else
>   REMOTE_CURL_NAMES = $(REMOTE_CURL_PRIMARY) $(REMOTE_CURL_ALIASES)
>   PROGRAM_OBJS += http-fetch.o
>   PROGRAMS += $(REMOTE_CURL_NAMES)
> - curl_check := $(shell (echo 070908; curl-config --vernum) | sort -r | 
> sed -ne 2p)
> - ifeq "$(curl_check)" "070908"
> + curl_check := $(shell curl-config --vernum 2>/dev/null)
> + ifneq "$(curl_check)" ""
>   ifndef NO_EXPAT
>   PROGRAM_OBJS += http-push.o
>   endif
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: commit gone after merge - how to debug?

[Igor Lautar]

On Mon, Nov 26, 2012 at 3:50 PM, Matthieu Moy
 wrote:
> What's possible is that someone had already merged the branch containing
> "new", got conflicts, and resolved it in favor of "old" somewhere in the
> history of your master branch.

This is exactly what happened. I've actually found a merge of origin
to mirror which reversed the change some time back and was
subsequently merged back to origin later on. Most probably human error
during merge.

Interestingly, this was my first thought as well, but I've must have
overlooked that particular merge the first time.

Anyhow, it sorted now, many thanks for your help,
Igor
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Fix typo in remote set-head usage

[Junio C Hamano]

Antoine Pelisse  writes:

> parenthesis are not matching in `builtin_remote_sethead_usage`
> as a square bracket is closing something never opened.
> ---
> This will also break all translation files, should I also send a patch
> to update them ?

"git grep -A2 -e 'remote set-head ' po/" tells me that we
already have both the correct variant and the broken one, and they
are both translated ;-) so I do not think we have much to worry
about the i18n fallout in this case, but thanks anyway for thinking
about it.

You would need to sign off your patch, but otherwise looks good to
me.

Thanks.


>
> Cheers,
> Antoine Pelisse
>
>  builtin/remote.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/builtin/remote.c b/builtin/remote.c
> index a5a4b23..937484d 100644
> --- a/builtin/remote.c
> +++ b/builtin/remote.c
> @@ -39,7 +39,7 @@ static const char * const builtin_remote_rm_usage[] = {
>  };
>
>  static const char * const builtin_remote_sethead_usage[] = {
> - N_("git remote set-head  (-a | -d | ])"),
> + N_("git remote set-head  (-a | -d | )"),
>   NULL
>  };
>
> --
> 1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/5] git-send-email: remove invalid addresses earlier

[Junio C Hamano]

Krzysztof Mazur  writes:

> Some addresses are passed twice to unique_email_list() and invalid addresses
> may be reported twice per send_message. Now we warn about them earlier
> and we also remove invalid addresses.
>
> This also removes using of undefined values for string comparison
> for invalid addresses in cc list processing.
>
> Signed-off-by: Krzysztof Mazur 
> ---

I think there are three kinds of address-looking things we deal
with:

 * Possibly invalid but meant for human consumption, e.g.

 Cc: Stable Kernel  # for v3.5 and upwards

   in the commit log message trailer.

 * Meant to be fed to our MSA, without losing the human readable
   part, e.g.

 Cc: Stable Kernel 

   in the header of the outgoing message.

 * Without the human-readable part, e.g.

 sta...@k.org

   that is returned by extract_valid_address.

My understanding is that our input typically comes from the first
kind and sanitize_address() is meant to massage it into the second
kind.  The last kind is to be used to drive the underlying sendmail
machinery and meant to go in the envelope (this includes message-id
generation).

I do not think send-email adds the first kind (invalid ones) in its
output, even though it reads them from its input and copy them to
its output in the e-mail body part of the payload, but I think it
adds new addresses to the e-mail header part of the payload (that is
what $from, @initial_to, @initial_cc and @bcclist are all about).
We would want to feed them in the third form (i.e. output from
extract-valid-address on them) when driving the underlying sendmail
machinery to place them in the envelope part, but they should be in
the second form when we place them on e-mail header lines.  As far
as I can tell, the resulting code looks correct in this regard.  The
addresses are sanitized into the second form upfront and validated
before they are placed in @initial_to and friends, and we carry the
second form around most of the time, until we call unique_email_list
in send_message to pass them through extract_valid_address to turn
them into the third form to drive the underlying sendmail.

I however found it a bit confusing while reading the callers of
validate_address{,_list} functions, which not just validate (and
warns) but return the ones that pass the test.  Perhaps we would
want a brief comment before validate_address, validate_address_list,
and extract_valid_address{,_or_die} to clarify what they are doing
(especially what they return)?

The result still feels somewhat yucky (the yuckiness comes primarily
from the current code, not from the patch but I am mostly focused on
the result after applying the patch), in that extract-valid-address
that has problem with invalid email addresses will still die when
fed an address that is not "sanitized" first, so any future patch
that adds a new address source may still have to suffer the same
problem the part that dealt with the Cc list suffered (which your
1/5 fixed earlier), but I do not offhand think of a good way to
reorganize them.  We could of course make validate_address() call
sanitize_address(), but that would be mostly redundant since the new
code sanitizes the input upfront.

So overall, looks good to me.  Thanks.

>  git-send-email.perl | 52 +++-
>  1 file changed, 39 insertions(+), 13 deletions(-)
>
> diff --git a/git-send-email.perl b/git-send-email.perl
> index 356f99d..5056fdc 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -786,9 +786,11 @@ sub expand_one_alias {
>  }
>  
>  @initial_to = expand_aliases(@initial_to);
> -@initial_to = (map { sanitize_address($_) } @initial_to);
> +@initial_to = validate_address_list(sanitize_address_list(@initial_to));
>  @initial_cc = expand_aliases(@initial_cc);
> +@initial_cc = validate_address_list(sanitize_address_list(@initial_cc));
>  @bcclist = expand_aliases(@bcclist);
> +@bcclist = validate_address_list(sanitize_address_list(@bcclist));
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Long clone time after "done."

[Uri Moszkowicz]

Hi guys,
Any further interest on this scalability problem or should I move on?

Thanks,
Uri

On Thu, Nov 8, 2012 at 5:35 PM, Uri Moszkowicz  wrote:
> I tried on the local disk as well and it didn't help. I managed to
> find a SUSE11 machine and tried it there but no luck so I think we can
> eliminate NFS and OS as significant factors now.
>
> I ran with perf and here's the report:
>
> ESC[31m69.07%ESC[m  git  /lib64/libc-2.11.1.so
>  [.] memcpy
> ESC[31m12.33%ESC[m  git
> /git-1.8.0.rc2.suse11/bin/git   [.]
> blk_SHA1_Block
> ESC[31m 5.11%ESC[m  git
> /zlib/local/lib/libz.so.1.2.5   [.]
> inflate_fast
> ESC[32m 2.61%ESC[m  git
> /zlib/local/lib/libz.so.1.2.5   [.]
> adler32
> ESC[32m 1.98%ESC[m  git  /lib64/libc-2.11.1.so
>  [.] _int_malloc
> ESC[32m 0.86%ESC[m  git  [kernel]
>  [k] clear_page_c
>
> Does this help? Machine has 396GB of RAM if it matters.
>
> On Thu, Nov 8, 2012 at 4:33 PM, Jeff King  wrote:
>> On Thu, Nov 08, 2012 at 04:16:59PM -0600, Uri Moszkowicz wrote:
>>
>>> I ran "git cat-file commit some-tag" for every tag. They seem to be
>>> roughly uniformly distributed between 0s and 2s and about 2/3 of the
>>> time seems to be system. My disk is mounted over NFS so I tried on the
>>> local disk and it didn't make a difference.
>>>
>>> I have only one 1.97GB pack. I ran "git gc --aggressive" before.
>>
>> Ah. NFS. That is almost certainly the source of the problem. Git will
>> aggressively mmap. I would not be surprised to find that RHEL4's NFS
>> implementation is not particularly fast at mmap-ing 2G files, and is
>> spending a bunch of time in the kernel servicing the requests.
>>
>> Aside from upgrading your OS or getting off of NFS, I don't have a lot
>> of advice.  The performance characteristics you are seeing are so
>> grossly off of what is normal that using git is probably going to be
>> painful. Your 2s cat-files should be more like .002s. I don't think
>> there's anything for git to fix here.
>>
>> You could try building with NO_MMAP, which will emulate it with pread.
>> That might fare better under your NFS implementation. Or it might be
>> just as bad.
>>
>> -Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCH] Option to revert order of parents in merge commit

[Junio C Hamano]

Kacper Kornet  writes:

>> Is there any interaction between this "pull --reverse-parents"
>> change and possible conflict resolution when the command stops and
>> asks the user for help?  For example, whom should "--ours" and "-X
>> ours" refer to?  Us, or the upstream?
>
> The change of order of parents happens at the very last moment, so
> "ours" in merge options is local version and "theirs" upstream.

That may be something that wants to go to the proposed commit log
message.  I am neutral on the "feature" (i.e. not against it but not
extremely enthusiastic about it either).

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 15/15] fast-export: don't handle uninteresting refs

[Junio C Hamano]

Johannes Schindelin  writes:

> If you changed your stance on the patch Sverre and I sent to fix this, we
> could get a non-partial fix for this.

This is long time ago so I may be misremembering the details, but I
thought the original patch was (ab)using object flags to mark "this
was explicitly asked for, even though some other range operation may
have marked it uninteresting".  Because it predated the introduction
of the rev_cmdline_info mechanism to record what was mentioned on
the command line separately from what objects are uninteresting
(i.e. object flags), it may have been one convenient way to record
this information, but it still looked unnecessarily ugly hack to me,
in that it allocated scarce object flag bits to represent a narrow
special case (iirc, only a freestanding "A" on the command line but
not "A" spelled in "B..A", or something), making it more expensive
to record other kinds of command line information in a way
consistent with the approach chosen (we do not want to waste object
flag bits in order to record "this was right hand side tip of the
symmetric difference range" and such).

If you are calling "do not waste object flags to represent one
special case among endless number of possibilities, as it will make
it impossible to extend it" my stance, that hasn't changed.

We added rev_cmdline_info since then so that we can tell what refs
were given from the command line in what way, and I thought that we
applied a patch from Sverre that uses it instead of the object
flags.  Am I misremembering things?

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] fast-export: Allow pruned-references in mark file

[Junio C Hamano]

Antoine Pelisse  writes:

> On Mon, Nov 26, 2012 at 12:37 PM, Felipe Contreras
>  wrote:
>> On Mon, Nov 26, 2012 at 5:03 AM, Junio C Hamano  wrote:
>>> Is this a safe and sane thing to do, and if so why?  Could you
>>> describe that in the log message here?
>> Why would fast-export try to export something that was pruned? Doesn't
>> that mean it wasn't reachable?
>
> Hello Junio,
> Hello Felipe,
>
> Actually the issue happened while using Felipe's branch with his
> git-remote-hg.  Everything was going fine until I (or did it run
> automatically, I dont remember) ran git gc that pruned unreachable
> objects. Of course some of the branch I had pushed to the hg remote
> had been changed (most likely rebased).  References no longer exists
> in the repository (cleaned by gc), but the reference still exists in
> mark file, as it was exported earlier.  Thus the failure when git
> fast-export reads the mark file.

You described that part very well in your proposed log message and I
got it just fine.

> Then, is it safe ?
> Updating the last_idnum as I do in the patch doesn't work because
> if the reference is the last, the number is going to be overwriten
> in the next run.
> From git point of view, I guess it is fine. The file is fully read at
> the beginning of fast-export and fully written at the end.

I am not sure I follow the above, but anyway, I think the patch does
is safe because (1) future "fast-export" will not refer to these
pruned objects in its output (we have decided that these pruned
objects are not used anywhere in the history so nobody will refer to
them) and (2) we still need to increment the id number so that later
objects in the marks file get assigned the same id number as they
were assigned originally (otherwise we will not name these objects
consistently when we later talk about them).

And I wanted to see that kind of reasoning behind the patch in the
proposed log message, because other people will need to refer to it
when they read "git log" output to understand the change.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 5/5] git-send-email: allow edit invalid email address

[Junio C Hamano]

Krzysztof Mazur  writes:

> In some cases the user may want to send email with "Cc:" line with
> email address we cannot extract. Now we allow user to extract
> such email address for us.
>
> Signed-off-by: Krzysztof Mazur 
> ---
>  git-send-email.perl | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/git-send-email.perl b/git-send-email.perl
> index d42dca2..9996735 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -851,10 +851,10 @@ sub extract_valid_address_or_die {
>  
>  sub validate_address {
>   my $address = shift;
> - if (!extract_valid_address($address)) {
> + while (!extract_valid_address($address)) {
>   print STDERR "error: unable to extract a valid address from: 
> $address\n";
> - $_ = ask("What to do with this address? ([q]uit|[d]rop): ",
> - valid_re => qr/^(?:quit|q|drop|d)/i,
> + $_ = ask("What to do with this address? ([q]uit|[d]rop|[e]dit): 
> ",
> + valid_re => qr/^(?:quit|q|drop|d|edit|e)/i,
>   default => 'q');
>   if (/^d/i) {
>   return undef;
> @@ -862,6 +862,9 @@ sub validate_address {
>   cleanup_compose_files();
>   exit(0);
>   }
> + $address = ask("Who should the email be sent to (if any)? ",
> + default => "",
> + valid_re => qr/\@.*\./, confirm_only => 1);

Not having this new code inside "elsif (/^e/) { }" feels somewhat
sloppy, even though it is not *too* bad.  Also do we know this
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)?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 5/5] git-send-email: allow edit invalid email address

[Krzysztof Mazur]

On Mon, Nov 26, 2012 at 09:08:34AM -0800, Junio C Hamano wrote:
> Krzysztof Mazur  writes:
> 
> > In some cases the user may want to send email with "Cc:" line with
> > email address we cannot extract. Now we allow user to extract
> > such email address for us.
> >
> > Signed-off-by: Krzysztof Mazur 
> > ---
> >  git-send-email.perl | 9 ++---
> >  1 file changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/git-send-email.perl b/git-send-email.perl
> > index d42dca2..9996735 100755
> > --- a/git-send-email.perl
> > +++ b/git-send-email.perl
> > @@ -851,10 +851,10 @@ sub extract_valid_address_or_die {
> >  
> >  sub validate_address {
> > my $address = shift;
> > -   if (!extract_valid_address($address)) {
> > +   while (!extract_valid_address($address)) {
> > print STDERR "error: unable to extract a valid address from: 
> > $address\n";
> > -   $_ = ask("What to do with this address? ([q]uit|[d]rop): ",
> > -   valid_re => qr/^(?:quit|q|drop|d)/i,
> > +   $_ = ask("What to do with this address? ([q]uit|[d]rop|[e]dit): 
> > ",
> > +   valid_re => qr/^(?:quit|q|drop|d|edit|e)/i,
> > default => 'q');
> > if (/^d/i) {
> > return undef;
> > @@ -862,6 +862,9 @@ sub validate_address {
> > cleanup_compose_files();
> > exit(0);
> > }
> > +   $address = ask("Who should the email be sent to (if any)? ",
> > +   default => "",
> > +   valid_re => qr/\@.*\./, confirm_only => 1);
> 
> 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.

Krzysiek
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 15/15] fast-export: don't handle uninteresting refs

[Johannes Schindelin]

Hi Junio,

On Sun, 25 Nov 2012, Junio C Hamano wrote:

> From: Johannes Schindelin 
> Subject: Re: [PATCH v3 4/4] fast-export: make sure refs are updated properly
> Date: Fri, 2 Nov 2012 16:17:14 +0100 (CET)
> Message-ID: 
> 
> 
> (which is $gmane/208946) that says:
> 
>   Note that
> 
>   $ git branch foo master~1
>   $ git fast-export foo master~1..master
> 
>   still does not update the "foo" ref, but a partial fix is better
>   than no fix.

If you changed your stance on the patch Sverre and I sent to fix this, we
could get a non-partial fix for this. You wanted a fix for a bigger
problem, though, which I am unwilling to fix because it is not my itch to
scratch and I have to balance my time.

Ciao,
Johannes
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git-fetch does not work from .git subdirectory

[Timur Tabi]

Patrik Gornicz wrote:
> Just a hunch but your remote's location uses a relative path 
> '../linux-2.6.git', perhaps git is messing up what the path is relative 
> to.

That makes sense.  Git is looking at the URL and not realizing that it's
relative to the home directory.

[remote "upstream"]
url = ../linux-2.6.git/
fetch = +refs/heads/*:refs/remotes/upstream/*

> Note sure what the fix will be though as it'll likely break existing 
> repositories that use relative paths either way. Can you try an 
> absolute path to see if that fixes thing?

If I change that to

[remote "upstream"]
url = /home/b04825/git/linux-2.6.git/
fetch = +refs/heads/*:refs/remotes/upstream/*

then everything works.

IMHO, this is a bug in git.

-- 
Timur Tabi
Linux kernel developer at Freescale

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: commit gone after merge - how to debug?

[Matthieu Moy]

[ Jumping back in time ]

Igor Lautar  writes:

>> Try this:
>>
>> commit=
>> # Show diff with first parent:
>> git diff "$commit" "$commit"^1
>> # Show diff with second parent:
>> git diff "$commit" "$commit"^2
>
> Yes, change is shown in commit^2, but actual file after merge does not have 
> it.

My commands had the wrong order. It should have been git diff
"$commit"^2 "$commit". So, it showed the reverse of the modification
introduced by the commit. If you see your change here, it means the
change was reverted by the merge.

My understanding of the situation up to now is:

M
|\
A C
|/
B

($commit = M, $commit^1 = A and $commit^2 = B)

Your file had a content (say, "old") at revision B. It changed content
(say, to "new") at revision C, and at some point. A did not change it so
it had the content "old". Then you merged, expected the merge commit M
to get content "new", and actually got "old".

So, your history looks like:

M (old)
| \
|  `---.
|   \
A (old)  C (new)
|   /
|  .---'
| /
|/
B (old)

and "git diff C M" shows the diff between new and old.

Something went wrong during the merge, I guess it used an ancestor (B
above) that had "new" as content. I don't see how this happened (rather
clearly, your history is more complex than my example above), but
"GIT_MERGE_VERBOSITY=5 git merge" will show you which common ancestor
was used, it may help.

What's possible is that someone had already merged the branch containing
"new", got conflicts, and resolved it in favor of "old" somewhere in the
history of your master branch.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: commit gone after merge - how to debug?

[Igor Lautar]

On Mon, Nov 26, 2012 at 3:19 PM, Matthieu Moy
 wrote:
> What about "git annotate  ^1"?

No change, line version goes back to when file was added.

> Was the merge completely automatic, or were there any conflict?

No conflicts at all. In fact, that particular file was not touched by
one side of merge, only by another. It seems like git ignored the
change, but still recorded history (shown only with --full-history).
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: commit gone after merge - how to debug?

[Matthieu Moy]

Igor Lautar  writes:

> git annotate  ^2
>  - shows line as being modified by a commit done after file was added
> - ie., state I would expect after a merge

What about "git annotate  ^1"?

Was the merge completely automatic, or were there any conflict?

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: commit gone after merge - how to debug?

[Igor Lautar]

On Mon, Nov 26, 2012 at 3:03 PM, Matthieu Moy
 wrote:
> Your initial message was about the output of "git log". Do you mean that
> the file, on the filesystem, does not have the line introduced by the
> commit?

Yes, sorry if I was not clear enough.

> If so, check the content registered in the repository too:
>
> git show :

Content shown is identical to the one in working copy, ie., it is
missing one line change.

git annotate  
 - shows that particular line as if it has originated from when the
file was originally added to repo.
git annotate  ^2
 - shows line as being modified by a commit done after file was added
- ie., state I would expect after a merge
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] fast-export: Allow pruned-references in mark file

[Antoine Pelisse]

> If that's the case, I don't think it should throw a warning even just skip 
> them.

Removing the warning seems fine to me.

> Then, in the actual export if some of these objects are referenced the
> export would fail anyway (but they won't).

Of course it will fail to export anything that requires the missing object.
As they are unreachable, it will be hard to provide a ref that needs
it anyway.

On the other hand, I'm afraid that your file
'.git/hg//marks-hg' needs consistent references to mark.
If a mark is removed, and then replaced by another object, can it
break somehow git-remote-hg ? If not, I can provide a simpler patch.
If it does, it will be more complicated.

Cheers,
Antoine
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] fast-export: Allow pruned-references in mark file

[Felipe Contreras]

On Mon, Nov 26, 2012 at 2:23 PM, Antoine Pelisse  wrote:
> On Mon, Nov 26, 2012 at 12:37 PM, Felipe Contreras
>  wrote:
>> On Mon, Nov 26, 2012 at 5:03 AM, Junio C Hamano  wrote:
>>> Is this a safe and sane thing to do, and if so why?  Could you
>>> describe that in the log message here?
>> Why would fast-export try to export something that was pruned? Doesn't
>> that mean it wasn't reachable?
>
> Hello Junio,
> Hello Felipe,
>
> Actually the issue happened while using Felipe's branch with his
> git-remote-hg.  Everything was going fine until I (or did it run
> automatically, I dont remember) ran git gc that pruned unreachable
> objects. Of course some of the branch I had pushed to the hg remote
> had been changed (most likely rebased).  References no longer exists
> in the repository (cleaned by gc), but the reference still exists in
> mark file, as it was exported earlier.  Thus the failure when git
> fast-export reads the mark file.

Ah, I see, so these objects are _before_ fast-export tries to do
anything, it's just importing the marks without any knowledge if these
objects are going to be used in the export or not.

If that's the case, I don't think it should throw a warning even just skip them.

Then, in the actual export if some of these objects are referenced the
export would fail anyway (but they won't).

Cheers.

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: commit gone after merge - how to debug?

[Matthieu Moy]

Igor Lautar  writes:

> Yes, change is shown in commit^2, but actual file after merge does not have 
> it.

Your initial message was about the output of "git log". Do you mean that
the file, on the filesystem, does not have the line introduced by the
commit?

If so, check the content registered in the repository too:

git show :

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: commit gone after merge - how to debug?

[Igor Lautar]

On Mon, Nov 26, 2012 at 2:38 PM, Matthieu Moy
 wrote:
> Igor Lautar  writes:
>> Somewhat, but it does not explain why the file no longer has that
>> change.
>
> It still has, but it's not shown by "git log ", probably because
> one of the parent of the merge commit introduces no change for this
> file, so one side of the merge is not needed to explain you how you went
> from the origin of time to the last commit.

No, the change is not there. See below.

> Try this:
>
> commit=
> # Show diff with first parent:
> git diff "$commit" "$commit"^1
> # Show diff with second parent:
> git diff "$commit" "$commit"^2

Yes, change is shown in commit^2, but actual file after merge does not have it.

I've double and triple checked, it is just not there. In the end, I've
cherry-picked the same commit after the merge and change is applied.
If change would be there after the merge, cherry-pick would not have
anything to do (whole commit is a one line change in single file).

So its not that the history is hidden, the change *is* missing after the merge.

Is there anything else I can try to figure out why its missing (other
than actually debugging git code/scripts)? Like debug output for each
change being considered/merged in?

Regards,
Igor
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: commit gone after merge - how to debug?

[Matthieu Moy]

Igor Lautar  writes:

> On Mon, Nov 26, 2012 at 2:23 PM, Matthieu Moy
>  wrote:
>> The other related question being: does reading the section "History
>> Simplification" in "man git-log" help? ;-)
>
> Somewhat, but it does not explain why the file no longer has that
> change.

It still has, but it's not shown by "git log ", probably because
one of the parent of the merge commit introduces no change for this
file, so one side of the merge is not needed to explain you how you went
from the origin of time to the last commit.

Try this:

commit=
# Show diff with first parent:
git diff "$commit" "$commit"^1
# Show diff with second parent:
git diff "$commit" "$commit"^2

> I can understand omitting history if end result is the same, but here
> it shouldn't be - I cannot find a commit that reversed that change, so
> the change should still be in after the merge?

revert is not the only situation that can lead to history
simplification. I'm no expert in the domain, but I think if you did the
same change in two branches, the merge will be candidate for history
simplification.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: commit gone after merge - how to debug?

[Igor Lautar]

On Mon, Nov 26, 2012 at 2:23 PM, Matthieu Moy
 wrote:
> The other related question being: does reading the section "History
> Simplification" in "man git-log" help? ;-)

Somewhat, but it does not explain why the file no longer has that
change. I can understand omitting history if end result is the same,
but here it shouldn't be - I cannot find a commit that reversed that
change, so the change should still be in after the merge?

The file in question was not modified on mirror, nor was modified on
origin after that change.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: commit gone after merge - how to debug?

[Igor Lautar]

On Mon, Nov 26, 2012 at 2:10 PM, Tomas Carnecky
 wrote:
> On Mon, 26 Nov 2012 14:06:09 +0100, Igor Lautar  wrote:
>> git log 
>>  - commit NOT shown in file history any more and file does not have this 
>> change
>
> does `git log --full-history ` show the commit?

Indeed it does.

Did the merge with verbosity set to 5. It says the commit I'm merging
in is virtual (probably as it is a merge commit in itself?).

Why would commit be left behind after merge? What kind of history
triggers this scenario?
Just trying to understand reasoning as its counter-intuitive to what I
know now. This may affect our workflow (ie., change it so we avoid it
happening).
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] fast-export: Allow pruned-references in mark file

[Antoine Pelisse]

On Mon, Nov 26, 2012 at 12:37 PM, Felipe Contreras
 wrote:
> On Mon, Nov 26, 2012 at 5:03 AM, Junio C Hamano  wrote:
>> Is this a safe and sane thing to do, and if so why?  Could you
>> describe that in the log message here?
> Why would fast-export try to export something that was pruned? Doesn't
> that mean it wasn't reachable?

Hello Junio,
Hello Felipe,

Actually the issue happened while using Felipe's branch with his
git-remote-hg.  Everything was going fine until I (or did it run
automatically, I dont remember) ran git gc that pruned unreachable
objects. Of course some of the branch I had pushed to the hg remote
had been changed (most likely rebased).  References no longer exists
in the repository (cleaned by gc), but the reference still exists in
mark file, as it was exported earlier.  Thus the failure when git
fast-export reads the mark file.

Then, is it safe ?
Updating the last_idnum as I do in the patch doesn't work because
if the reference is the last, the number is going to be overwriten
in the next run.
>From git point of view, I guess it is fine. The file is fully read at
the beginning of fast-export and fully written at the end.
The issue is more for git-remote-hg that keeps track of
matches between git marks and hg commits. The marks are going to
change and be overriden. It will most likely need to read the mark
file to see if a ref has changed, and update it's dictionary.

One of the solution I'm thinking of, is to update the mark file
with marks of newly exported objects instead of recreating it,
and let obsolete references in the file. But of course that is
not acceptable.

Cheers,
Antoine
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: commit gone after merge - how to debug?

[Matthieu Moy]

Tomas Carnecky  writes:

> On Mon, 26 Nov 2012 14:06:09 +0100, Igor Lautar  wrote:
>> git log 
>>  - commit NOT shown in file history any more and file does not have this 
>> change
>
> does `git log --full-history ` show the commit?

The other related question being: does reading the section "History
Simplification" in "man git-log" help? ;-)

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Python extension commands in git - request for policy change

[Felipe Contreras]

On Sun, Nov 25, 2012 at 11:11 PM, Eric S. Raymond  wrote:
> Felipe Contreras :
>> And are you going to be around to spot them? It seems my patches for
>> git-remote-hg slipped by your watch, because it seems they use stuff
>> specific to python 2.7.
>
> The dev group hasn't decided (in whatever way it decides these
> things) to require 2.6 yet.  When and if it does, I will volunteer my
> services as a Python expert to audit the in-tree Python code for 2.6
> conformance and assist the developers in backporting if required.
> I will also make myself available to audit future submissions.

What dev group?

> I think you know who I am. Junio and the other senior devs certainly
> know where to find me. I've been making promises like this, and
> *keeping* them, for decades.  Please stop wasting our time with
> petulant display.

All right, you don't wand feedback, fine.

If you need me I'll be rewriting python code to ruby.

Cheers.

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Python extension commands in git - request for policy change

[Felipe Contreras]

On Sun, Nov 25, 2012 at 10:56 PM, Eric S. Raymond  wrote:
> Felipe Contreras :
>> And gitk is an integral part of git. But if you have different
>> numbers, what are they?
>
> I looked at the Makefile.  I saw that there are shell variables that collect
> C commands, shell command, Perl commands, and Python commands.  There are no
> collections of other commands.

I suppose you are talking about BUILT_INS, and SCRIPT_FOO, but tcl
scripts don't need no SCRIPT_FOO stuff, because they don't need to be
regenerated, in fact, I don't think the shell scripts need to be
regenerated, but that's not important, what is important is this:

all::
ifndef NO_TCLTK
$(QUIET_SUBDIR0)git-gui $(QUIET_SUBDIR1) 
gitexecdir='$(gitexec_instdir_SQ)' all
$(QUIET_SUBDIR0)gitk-git $(QUIET_SUBDIR1) all
endif

Why are you ignoring that?

> That makes them the top languages in the universe we are concerned about

According to whom?

I find it very curious how you are arguing for a change in the status
quo to move more towards python, and the basis you are using for
choosing python, and not ruby, or other scripting language is
precisely the status quo. However, the only scripts using python are
these:

SCRIPT_PYTHON += git-remote-testgit.py
SCRIPT_PYTHON += git-p4.py

I already re-wrote git-remote-testgit in bash, and it's dubious
whether or not git-remote-testpy (the new name for this old test) will
fulfill any service. Than means 43% of the current python code is
gone.

And what happens if I rewrite git-p4 in ruby? Would you then argue
that ruby is the way to go because 1% of the *current* code-base uses
it?

Interestingly, according to Wikipedia git is written in: C, Bourne
Shell, Tcl, Perl. That seems to be the case.

> Please don't waste further time on quibbling.  We all know that gitk is
> an uncomfortable special case and that the project would be far better
> off, maintainability-wise, if it were successfully ported to one if these
> other languages.

As I said, gitk is integral to the git experience. Of course you are
free to disagree, but according to the last user survey 57% of the
responders used some kind of graphical tool (e.g. gitk, tig). How many
use gitk, and how many use something else, we don't really know, but
what we know is that gitk is distributed *by default*.

Nobody is arguing that gitk should not be distributed by default, just
like nobody is arguing that git-p4 shouldn't, but we *know* very few
people use git-p4 (1% according to the survey), and we can reasonably
assume that many more use gitk.

You cannot have your cake and eat it at the same time. If you use the
amount of code as a measure, then you have to agree that Tcl/Tk is a
way bigger language than python in the mainline git world. If not,
then by all means, show us the numbers. But you can't say "the
important languages are A, B, and D, C doesn't count because I don't
like it, and E doesn't count either because we should draw the line at
three", that seems awfully convenient to push your agenda.

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

> Trying to catch me out by triumphantly pointing at gitk is...juvenile.

Isn't that what you are doing by triumphantly pointing at git-p4?

Sorry, if you want to cut the line for the languages that git should
use right now at three, then python is out. Maybe in a couple of
years. Maybe. But I doubt it.

Cheers.

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: commit gone after merge - how to debug?

[Tomas Carnecky]

On Mon, 26 Nov 2012 14:06:09 +0100, Igor Lautar  wrote:
> git log 
>  - commit NOT shown in file history any more and file does not have this 
> change

does `git log --full-history ` show the commit?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

commit gone after merge - how to debug?

[Igor Lautar]

Hi,

This looks really weird and I cannot explain why it occurs.

Setup is as follows:
 - origin
 - mirror
 - local clone

Reference repository is origin from where builds are done etc.
Parallel to that, we keep a mirror that is synced manually
(fetch/merge/push).

I do this from my local clone (which is mostly just tracking origin
and mirror, no local branches).

What happened is that after a merge of mirror/master into local
master, a commit (that also exists on origin/master) is lost.

Lost as in:
pre-merge:
git log 
 - commit shown in history
git merge mirror/master
 - no conflicts
git log 
 - commit NOT shown in file history any more and file does not have this change

Doing git log shows commit as being present in repository history. One
interesting point is that one of the parents is previous merge commit
of same branches.

Unfortunately, I cannot open up repository for public access, but
would appreciate any pointers how to debug this.

git fsck finds some dangling blobs/commits, but no other
warnings/errors, I can clone repo just fine, everything seams in
order.

How can I debug what the merge is doing?

git version 1.7.12.1 on mac:
Darwin 12.2.0 Darwin Kernel Version 12.2.0: Sat Aug 25 00:48:52 PDT
2012; root:xnu-2050.18.24~1/RELEASE_X86_64 x86_64

Regards,
Igor

PS. please keep me in CC, I'm not on list
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Can I zip a git repo without losing anything?

[Konstantin Khomoutov]

On Mon, 26 Nov 2012 04:55:10 +
Carl Smith  wrote:

> After suggesting using zip files to move our projects around, I was
> told that you can not zip a git repo without loosing all the history.
> This didn't make sense to me, but two people told me the same thing,
> so I wasn't sure. I think they may have been confusing the zipped file
> you can download from GitHub with a zipped git repo.
> 
> If someone could put me straight on this, I'd really appreciate it.

To amend the already provided answer -- if you need to move repos
around using the sneakernet, the tool you should probably use is
`git bundle`.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCH] Option to revert order of parents in merge commit

[Kacper Kornet]

On Fri, Nov 23, 2012 at 06:58:49PM -0800, Junio C Hamano wrote:
> Kacper Kornet  writes:

> > The following patch is an attempt to implement this idea.

> I think "revert" is a wrong word (implying you have already done
> something and you are trying to defeat the effect of that old
> something), and you meant to say "reverse" (i.e. the opposite of
> normal) or something.

You are right. Probably transpose is the best description what the patch
really does.

> I am unsure about the usefulness of this, though.

> After completing a topic on branch A, you would merge it to your own
> copy of the integration branch (e.g. 'master') and try to push,
> which may be rejected due to non-fast-forwardness:

> $ git checkout master
> $ git merge A
> $ git push

> At that point, if you _care_ about the merge parent order, you could
> do this (still on 'master'):

> $ git fetch origin
> $ git reset --hard origin/master
> $ git merge A
> $ test test test
> $ git push

> With --reverse-parents, it would become:

> $ git pull --reverse-parents
> $ test test test
> $ git push

> which certainly is shorter and looks simpler.  The workflow however
> would encourage people to work directly on the master branch, which
> is a bit of downside.

Our developers work mainly on master branches. The project consists of
many thousands independent git repositories, and at the given time a
developer usually wants to make only one commit in the given repository
and push his changes upstream. So he usually doesn't care to make a
branch.  Then after failed pushed, one needs to add creation and removal
of temporary branch (see the commit message of the suggested patch).
The possibility to do git pull --reverse-parent would make the life
easier in this case.

> Is there any interaction between this "pull --reverse-parents"
> change and possible conflict resolution when the command stops and
> asks the user for help?  For example, whom should "--ours" and "-X
> ours" refer to?  Us, or the upstream?

The change of order of parents happens at the very last moment, so
"ours" in merge options is local version and "theirs" upstream.

-- 
  Kacper Kornet
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] pack-objects: compression level for non-blobs

[David Michael Barr]

> Add config pack.graphcompression similar to pack.compression.
> Applies to non-blob objects and if unspecified falls back to pack.compression.
> 
> We may identify objects compressed with level 0 by their leading bytes.
> Use this to force recompression when the source and target levels mismatch.
> Limit its application to when the config pack.graphcompression is set.
> 
> Signed-off-by: David Michael Barr  (mailto:b...@rr-dav.id.au)>
> ---
> builtin/pack-objects.c | 49 +
> 1 file changed, 45 insertions(+), 4 deletions(-)
> 
> I started working on this just before taking a vacation,
> so it's been a little while coming.
> 
> The intent is to allow selective recompression of pack data.
> For small objects/deltas the overhead of deflate is significant.
> This may improve read performance for the object graph.
> 
> I ran some unscientific experiments with the chromium repository.
> With pack.graphcompression = 0, there was a 2.7% increase in pack size.
> I saw a 35% improvement with cold caches and 43% otherwise on git log --raw.

I neglected to mention that this is a WIP. I get failures with certain 
repositories: 

fatal: delta size changed

--
David Michael Barr

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] fast-export: Allow pruned-references in mark file

[Felipe Contreras]

On Mon, Nov 26, 2012 at 5:03 AM, Junio C Hamano  wrote:
> Antoine Pelisse  writes:
>
>> fast-export can fail because of some pruned-reference when importing a
>> mark file.
>>
>> The problem happens in the following scenario:
>>
>> $ git fast-export --export-marks=MARKS master
>> (rewrite master)
>> $ git prune
>> $ git fast-export --import-marks=MARKS master
>>
>> This might fail if some references have been removed by prune
>> because some marks will refer to non-existing commits.
>>
>> Let's warn when we have a mark for a commit we don't know.
>> Also, increment the last_idnum before, so we don't override
>> the mark.
>
> Is this a safe and sane thing to do, and if so why?  Could you
> describe that in the log message here?

Why would fast-export try to export something that was pruned? Doesn't
that mean it wasn't reachable?

Essentially, if 'git rev-list $foo' can't possibly export this pruned
object, why would 'git fast-export $foo' would?

Cheers.

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 0/7] New remote-bzr remote helper

[Felipe Contreras]

On Mon, Nov 26, 2012 at 5:09 AM, Junio C Hamano  wrote:
> Felipe Contreras  writes:
>
>> On Sun, Nov 11, 2012 at 3:19 PM, Felipe Contreras
>>  wrote:
>>> This is a re-roll of the previous series to add support to fetch and push
>>> special modes, and refactor some related code.
>>
>> It seems this one got forgotten, I only see v2 in pu.
>
> Oops; I think that was fell through the cracks during the maintainer
> hand-off.  As the previous one has already been cooking in 'next'
> for a week or so, I would appreciate if you send incremental updates
> to fix or enhance what is in there.

Yes, that's what I have planned for the next patches, as I already did
for remote-hg, but the changes in remote-bzr were a bit bigger.

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Fix bash completion when `egrep` is aliased to `egrep --color=always`

[Frans Klaver]

On Mon, Nov 26, 2012 at 12:23 PM, Adam Tkac  wrote:

> Good idea, thanks. Improved patch is attached.

It is custom on this list to mail the patches, rather than attaching
them, so people can review your changes in-line. You can read more
about it in in git/Documentation/SubmittingPatches.

Cheers,
Frans
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html