* [PATCH] Initial manually svn property setting support for git-svn
From: David Fraser @ 2009-09-16 7:02 UTC (permalink / raw)
To: git; +Cc: David Moore
In-Reply-To: <1482075216.1261253084509966.JavaMail.root@klofta.sjsoft.com>
[-- Attachment #1: Type: text/plain, Size: 922 bytes --]
This basically stores an attribute 'svn-properties' for each file that needs them changed, and then sets the properties when committing.
Issues remaining:
* The way it edits the .gitattributes file is suboptimal - it just appends to the end the latest version
* It could use the existing code to get the current svn properties to see if properties need to be changed; but this doesn't work on add
* It would be better to cache all the svn properties locally - this could be done automatically in .gitattributes but I'm not sure everyone would want this, etc
* No support for deleting properties
Usage is:
git svn propset PROPNAME PROPVALUE PATH
Added minimal documentation for git-svn propset
Signed-off-by: David Fraser <davidf@sjsoft.com>
---
Documentation/git-svn.txt | 5 ++
git-svn.perl | 95 ++++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 99 insertions(+), 1 deletions(-)
[-- Attachment #2: 0001-Initial-manually-svn-property-setting-support-for-gi.patch --]
[-- Type: text/x-patch, Size: 7329 bytes --]
>From 521ed4fc7c877269fb029b9494ef57300c722a10 Mon Sep 17 00:00:00 2001
From: David Fraser <davidf@sjsoft.com>
Date: Wed, 16 Sep 2009 13:28:00 +0200
Subject: [PATCH] Initial manually svn property setting support for git-svn.
This basically stores an attribute 'svn-properties' for each file that needs them changed, and then sets the properties when committing.
Issues remaining:
* The way it edits the .gitattributes file is suboptimal - it just appends to the end the latest version
* It could use the existing code to get the current svn properties to see if properties need to be changed; but this doesn't work on add
* It would be better to cache all the svn properties locally - this could be done automatically in .gitattributes but I'm not sure everyone would want this, etc
* No support for deleting properties
Usage is:
git svn propset PROPNAME PROPVALUE PATH
Added minimal documentation for git-svn propset
Signed-off-by: David Fraser <davidf@sjsoft.com>
---
Documentation/git-svn.txt | 5 ++
git-svn.perl | 95 ++++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 99 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 1812890..b14bcf0 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -345,6 +345,11 @@ Any other arguments are passed directly to 'git log'
Gets the Subversion property given as the first argument, for a
file. A specific revision can be specified with -r/--revision.
+'propset'::
+ Sets the Subversion property given as the first argument, to the value
+ given as the second argument, for files specifed as the remaining
+ arguments. The property will be sent with the next commit.
+
'show-externals'::
Shows the Subversion externals. Use -r/--revision to specify a
specific revision.
diff --git a/git-svn.perl b/git-svn.perl
index e0ec258..aaf92fb 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -80,7 +80,7 @@ my ($_stdin, $_help, $_edit,
$_version, $_fetch_all, $_no_rebase, $_fetch_parent,
$_merge, $_strategy, $_dry_run, $_local,
$_prefix, $_no_checkout, $_url, $_verbose,
- $_git_format, $_commit_url, $_tag);
+ $_git_format, $_commit_url, $_tag, $_set_svn_props);
$Git::SVN::_follow_parent = 1;
$_q ||= 0;
my %remote_opts = ( 'username=s' => \$Git::SVN::Prompt::_username,
@@ -147,6 +147,7 @@ my %cmd = (
'dry-run|n' => \$_dry_run,
'fetch-all|all' => \$_fetch_all,
'commit-url=s' => \$_commit_url,
+ 'set-svn-props=s' => \$_set_svn_props,
'revision|r=i' => \$_revision,
'no-rebase' => \$_no_rebase,
%cmt_opts, %fc_opts } ],
@@ -171,6 +172,9 @@ my %cmd = (
'propget' => [ \&cmd_propget,
'Print the value of a property on a file or directory',
{ 'revision|r=i' => \$_revision } ],
+ 'propset' => [ \&cmd_propset,
+ 'Set the value of a property on a file or directory - will be set on commit',
+ {} ],
'proplist' => [ \&cmd_proplist,
'List all properties of a file or directory',
{ 'revision|r=i' => \$_revision } ],
@@ -892,6 +896,64 @@ sub cmd_propget {
print $props->{$prop} . "\n";
}
+sub check_attr
+{
+ my ($attr,$path) = @_;
+ if ( open my $fh, '-|', "git", "check-attr", $attr, "--", $path )
+ {
+ my $val = <$fh>;
+ close $fh;
+ $val =~ s/^[^:]*:\s*[^:]*:\s*(.*)\s*$/$1/;
+ return $val;
+ }
+ else
+ {
+ return undef;
+ }
+}
+
+# cmd_propset (PROPNAME, PROPVAL, PATH)
+# ------------------------
+# Adjust the SVN property PROPNAME to PROPVAL for PATH.
+sub cmd_propset {
+ my ($propname, $propval, $path) = @_;
+ $path = '.' if not defined $path;
+ $path = $cmd_dir_prefix . $path;
+ usage(1) if not defined $propname;
+ usage(1) if not defined $propval;
+ my $file = basename($path);
+ my $dn = dirname($path);
+ my $current_properties = check_attr( "svn-properties", $path );
+ my $new_properties = "";
+ if ($current_properties eq "unset" || $current_properties eq "" || $current_properties eq "set") {
+ $new_properties = "$propname=$propval";
+ } else {
+ # TODO: handle combining properties better
+ my @props = split(/;/, $current_properties);
+ my $replaced_prop = 0;
+ foreach my $prop (@props) {
+ # Parse 'name=value' syntax and set the property.
+ if ($prop =~ /([^=]+)=(.*)/) {
+ my ($n,$v) = ($1,$2);
+ if ($n eq $propname)
+ {
+ $v = $propval;
+ $replaced_prop = 1;
+ }
+ if ($new_properties eq "") { $new_properties="$n=$v"; }
+ else { $new_properties="$new_properties;$n=$v"; }
+ }
+ }
+ if ($replaced_prop eq 0) {
+ $new_properties = "$new_properties;$propname=$propval";
+ }
+ }
+ my $attrfile = "$dn/.gitattributes";
+ open my $attrfh, '>>', $attrfile or die "Can't open $attrfile: $!\n";
+ # TODO: don't simply append here if $file already has svn-properties
+ print $attrfh "$file svn-properties=$new_properties\n";
+}
+
# cmd_proplist (PATH)
# -------------------
# Print the list of SVN properties for PATH.
@@ -4185,6 +4247,33 @@ sub apply_autoprops {
}
}
+sub apply_manualprops {
+ my ($self, $file, $fbat) = @_;
+ my $path = $cmd_dir_prefix . $file;
+ my $pending_properties = ::check_attr( "svn-properties", $path );
+ if ($pending_properties eq "") { return; }
+ # Parse the list of properties to set.
+ my @props = split(/;/, $pending_properties);
+ # TODO: get existing properties to compare to - this fails for add so currently not done
+ # my $existing_props = ::get_svnprops($file);
+ my $existing_props = {};
+ # TODO: caching svn properties or storing them in .gitattributes would make that faster
+ foreach my $prop (@props) {
+ # Parse 'name=value' syntax and set the property.
+ if ($prop =~ /([^=]+)=(.*)/) {
+ my ($n,$v) = ($1,$2);
+ for ($n, $v) {
+ s/^\s+//; s/\s+$//;
+ }
+ if (defined $existing_props->{$n} && $existing_props->{$n} eq $v) {
+ my $needed = 0;
+ } else {
+ $self->change_file_prop($fbat, $n, $v);
+ }
+ }
+ }
+}
+
sub A {
my ($self, $m) = @_;
my ($dir, $file) = split_path($m->{file_b});
@@ -4193,6 +4282,7 @@ sub A {
undef, -1);
print "\tA\t$m->{file_b}\n" unless $::_q;
$self->apply_autoprops($file, $fbat);
+ $self->apply_manualprops($file, $fbat);
$self->chg_file($fbat, $m);
$self->close_file($fbat,undef,$self->{pool});
}
@@ -4204,6 +4294,7 @@ sub C {
my $fbat = $self->add_file($self->repo_path($m->{file_b}), $pbat,
$self->url_path($m->{file_a}), $self->{r});
print "\tC\t$m->{file_a} => $m->{file_b}\n" unless $::_q;
+ $self->apply_manualprops($file, $fbat);
$self->chg_file($fbat, $m);
$self->close_file($fbat,undef,$self->{pool});
}
@@ -4223,6 +4314,7 @@ sub R {
my $fbat = $self->add_file($self->repo_path($m->{file_b}), $pbat,
$self->url_path($m->{file_a}), $self->{r});
print "\tR\t$m->{file_a} => $m->{file_b}\n" unless $::_q;
+ $self->apply_manualprops($file, $fbat);
$self->apply_autoprops($file, $fbat);
$self->chg_file($fbat, $m);
$self->close_file($fbat,undef,$self->{pool});
@@ -4239,6 +4331,7 @@ sub M {
my $fbat = $self->open_file($self->repo_path($m->{file_b}),
$pbat,$self->{r},$self->{pool});
print "\t$m->{chg}\t$m->{file_b}\n" unless $::_q;
+ $self->apply_manualprops($file, $fbat);
$self->chg_file($fbat, $m);
$self->close_file($fbat,undef,$self->{pool});
}
--
1.6.0.4
^ permalink raw reply related
* Re: [PATCH] archive: Refuse to write the archive to a terminal.
From: Reece Dunn @ 2009-09-16 11:48 UTC (permalink / raw)
To: Mikael Magnusson; +Cc: Johannes Sixt, Josh Triplett, git, gitster
In-Reply-To: <237967ef0909160427m4d7de120tf5ef3176f75123ad@mail.gmail.com>
2009/9/16 Mikael Magnusson <mikachu@gmail.com>:
> 2009/9/16 Johannes Sixt <j.sixt@viscovery.net>:
>> Josh Triplett schrieb:
>>> I considered adding a -f/--force option, like gzip has, but writing an
>>> archive to a tty seems like a sufficiently insane use case that I'll let
>>> whoever actually needs that write the patch for it. ;)
>>
>> How about '--output -' instead?
>
> You could always just add '|cat'.
Except when running on Windows. Yes MSYS and cygwin provide a version
of cat, but this cannot be guaranteed (e.g. with the series to support
building with MSVC).
The `--output -` / `-o -` syntax looks reasonable (the issue with
using -f/--force is: what are you forcing the operation of?). Is -
used elsewhere in git for specifying stdout?
Also, the die message might be more useful (and in keeping with the
other git commands) by showing the 'inline context help'; something
like:
Failed to generate the archive: output is a terminal.
Please specify the file to write to (using `-o archive.tar`) or
redirect the output (e.g. `... | gzip`).
If you want to write the archive out to the terminal, use `-o -`
to force the operation.
- Reece
^ permalink raw reply
* git-svn-problem: Unnecessary downloading entire branch?
From: Martin Larsson @ 2009-09-16 11:53 UTC (permalink / raw)
To: git
I have a local git-copy of the company svn-repository. The git-copy is
up-to-date (git svn fetch). I then add a new branch in the
svn-repository (svn cp http://.../trunk http://...branches/JIRA-4444).
When I then do 'git svn fetch' again, it pulls all the files from the
svn-repository.
I was expecting it to only pull the fact that a new branch was made
(taking milliseconds), not all the files in the branch (taking more than
half an hour to complete). Why does it need to transfer all the files?
I did have problems getting the original svn-repository. It took several
days and stopped several times in the process. Each time it stopped, I
just issued 'git svn fetch' again and it seemed to continue. Could this
be related? How could I make a better copy?
M.
^ permalink raw reply
* System wide gitattributes
From: David Förster @ 2009-09-16 11:50 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 356 bytes --]
Hi there,
from the documentation I understand that things like external diff tools
can be set up in a gitattributes file per repository (or subfolder).
Why is there no support for a ~/.gitattributes file? This would be very
handy, for example to always get a textual diff of OpenDocument files.
Regards,
- David
ps: Please cc, I'm not on the list.
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3336 bytes --]
^ permalink raw reply
* Re: System wide gitattributes
From: Rustom Mody @ 2009-09-16 12:16 UTC (permalink / raw)
To: David Förster; +Cc: git
In-Reply-To: <4AB0D0EB.5080105@andrena.de>
2009/9/16 David Förster <david.foerster@andrena.de>:
> Hi there,
>
> from the documentation I understand that things like external diff tools can
> be set up in a gitattributes file per repository (or subfolder).
>
> Why is there no support for a ~/.gitattributes file? This would be very
> handy, for example to always get a textual diff of OpenDocument files.
>
They are there; see
http://www.kernel.org/pub/software/scm/git/docs/git-config.html#FILES
^ permalink raw reply
* Re: System wide gitattributes
From: Matthieu Moy @ 2009-09-16 12:53 UTC (permalink / raw)
To: Rustom Mody; +Cc: David Förster, git
In-Reply-To: <f46c52560909160516w1d888a23yedd1fafae515bfbe@mail.gmail.com>
Rustom Mody <rustompmody@gmail.com> writes:
> 2009/9/16 David Förster <david.foerster@andrena.de>:
>> Hi there,
>>
>> from the documentation I understand that things like external diff tools can
>> be set up in a gitattributes file per repository (or subfolder).
>>
>> Why is there no support for a ~/.gitattributes file? This would be very
>> handy, for example to always get a textual diff of OpenDocument files.
>>
>
> They are there; see
>
> http://www.kernel.org/pub/software/scm/git/docs/git-config.html#FILES
~/.gitconfig is there, but I don't see a ~/.gitattributes file
mentionned in this page ...
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH] archive: Refuse to write the archive to a terminal.
From: Matthieu Moy @ 2009-09-16 12:57 UTC (permalink / raw)
To: Reece Dunn; +Cc: Mikael Magnusson, Johannes Sixt, Josh Triplett, git, gitster
In-Reply-To: <3f4fd2640909160448x1fbb7a64s1ce0adca2af5010@mail.gmail.com>
Reece Dunn <msclrhd@googlemail.com> writes:
> 2009/9/16 Mikael Magnusson <mikachu@gmail.com>:
>> 2009/9/16 Johannes Sixt <j.sixt@viscovery.net>:
>>> Josh Triplett schrieb:
>>>> I considered adding a -f/--force option, like gzip has, but writing an
>>>> archive to a tty seems like a sufficiently insane use case that I'll let
>>>> whoever actually needs that write the patch for it. ;)
>>>
>>> How about '--output -' instead?
>>
>> You could always just add '|cat'.
>
> Except when running on Windows. Yes MSYS and cygwin provide a version
> of cat, but this cannot be guaranteed (e.g. with the series to support
> building with MSVC).
In general, autodectection features sometimes fail, so it's good to
have an explicit override option.
> The `--output -` / `-o -` syntax looks reasonable
I like this too.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: Gource - new GL Visualisation for git repositories
From: Alex Riesen @ 2009-09-16 13:02 UTC (permalink / raw)
To: Reece Dunn; +Cc: Sam Vilain, Git Mailing List
In-Reply-To: <3f4fd2640909160416n7c0ac92eo3f055d6c45f9c0a2@mail.gmail.com>
On Wed, Sep 16, 2009 at 13:16, Reece Dunn <msclrhd@googlemail.com> wrote:
> In addition to this, for large projects that span a long time (5 or
> more years), it would be nice to speed these up (possibly control the
> rate as a command-line parameter).
It has a little of that, try gource -h (I forgot the option name).
Not _much_ faster, though.
^ permalink raw reply
* Re: [PATCH] gitk: restore wm state to normal before saving geometry information
From: Pat Thoyts @ 2009-09-15 12:03 UTC (permalink / raw)
To: git; +Cc: Alexey Borzenkov
In-Reply-To: <1252437756-81986-1-git-send-email-snaury@gmail.com>
Alexey Borzenkov <snaury@gmail.com> writes:
>gitk now includes patches for saving and restoring wm state, however
>because it saves wm geometry when window can still be maximized the
>maximize/restore button becomes useless after restarting gitk (you
>will get a huge displaced window if you try to restore it). This
>patch fixes this issue by storing window geometry in normal state.
>
I tried this patch on windows and I find that it causes the columns in
the top view to creep each time you restart the application. This is I
think due to the way this patch sets the state to normal before
recording all the settings.
I will post an alternative patch that records the normal geometry
whenever it changes instead which seems to work better for me.
--
Pat Thoyts http://www.patthoyts.tk/
PGP fingerprint 2C 6E 98 07 2C 59 C8 97 10 CE 11 E6 04 E0 B9 DD
^ permalink raw reply
* Re: Pair Programming Workflow Suggestions
From: Tim Visher @ 2009-09-16 13:35 UTC (permalink / raw)
To: Sean Estabrooks; +Cc: Git Mailing List
In-Reply-To: <BLU0-SMTP195165E447A0C42386D083AEE30@phx.gbl>
On Tue, Sep 15, 2009 at 2:14 PM, Sean Estabrooks <seanlkml@sympatico.ca> wrote:
> On Tue, 15 Sep 2009 13:43:17 -0400
> Tim Visher <tim.visher@gmail.com> wrote:
>
> [...]
>> It would be nicer to
>> have an arbitrary number of authors that can all exist separately, but
>> I'm fairly certain that git does not support that.
>
> Tim,
>
> If you're just looking for a way to quickly switch the author information
> quickly between individual commits. You could create a shell alias for
> each of the programmers that does:
>
> export GIT_AUTHOR_NAME="some name" GIT_AUTHOR_EMAIL="name@where.com"
>
> This will override the global and per repo configured author information
> for all subsequent commits.
That is an interesting idea. My point is really that having a
committer and an author is something that makes sense in terms of
non-pairing. Especially in the OS world where developers may never
even get to meet, let alone code together, one developer writes a
feature somewhere and then submits it to the maintainer and the
maintainer puts it in. Pairing, on the other hand, is much more
tightly integrated than that. Just like in Brian's post, it's really
a situation of Dev1 _&_ Dev2 wrote this feature, but one of them
happened to be typing and doing most of the nitty-gritty developing.
Changing the authors between committs almost seems to introduce an
arbitrary level of distinction where it's no longer _both_ but _one
then the other_. Does that make my question any clearer?
--
In Christ,
Timmy V.
http://burningones.com/
http://five.sentenc.es/ - Spend less time on e-mail
^ permalink raw reply
* Re: Pair Programming Workflow Suggestions
From: Tim Visher @ 2009-09-16 13:36 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Git Mailing List
In-Reply-To: <m3zl8w2hpf.fsf@localhost.localdomain>
On Tue, Sep 15, 2009 at 2:20 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> Tim Visher <tim.visher@gmail.com> writes:
>
>> I'm interested in hearing how people use Git for pair programming.
>> Specifically, how do you document that you are programming in pairs.
>
> [...]
>
>> I did find Brian Helmkamp's script
>> http://www.brynary.com/2008/9/1/setting-the-git-commit-author-to-pair-programmers-names
>> but that's not really what I'm looking for. [...]
>
> I'm not sure if this would help you, but take a look at "Pair
> Programming & git & github & Gravatar & You & You" blog post by Jon
> "Lark" Larkowski from May 30, 2009:
>
> http://blog.l4rk.com/2009/05/pair-programming-git-github-gravatar.html
Unfortunately my company firewall is blocking that post. I'll have to
read it later. Thanks for the pointer though!
--
In Christ,
Timmy V.
http://burningones.com/
http://five.sentenc.es/ - Spend less time on e-mail
^ permalink raw reply
* Direct ancestors from commit to HEAD
From: Gonsolo @ 2009-09-16 14:01 UTC (permalink / raw)
To: git
Is there a way to see only the direct line of (merge) ancestors from
patch to HEAD? Something like:
commit 0cb583fd2862f19ea88b02eb307d11c09e51e2f8
Merge: 723e9db... a2d1056...
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Tue Sep 15 10:01:16 2009 -0700
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6
commit 88512935a24305fea7aecc9ba4d675869e97fc2a
Merge: 8a62bab... 6b26dea...
Author: David S. Miller <davem@davemloft.net>
Date: Fri Aug 14 12:27:19 2009 -0700
Merge branch 'master' of
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6
commit edd7fc7003f31da48d06e215a93ea966a22c2a03
Author: Nick Kossifidis <mick@madwifi-project.org>
Date: Mon Aug 10 03:29:02 2009 +0300
ath5k: Wakeup fixes
Here I can see exactly how the ath5k patch came to mainline and since
when it is there.
^ permalink raw reply
* Re: Pair Programming Workflow Suggestions
From: Nicolas Sebrecht @ 2009-09-16 14:17 UTC (permalink / raw)
To: Tim Visher; +Cc: Sean Estabrooks, Git Mailing List, Nicolas Sebrecht
In-Reply-To: <c115fd3c0909160635x4d7368aeg4370668d765fd242@mail.gmail.com>
The 16/09/09, Tim Visher wrote:
>
> Pairing, on the other hand, is much more
> tightly integrated than that. Just like in Brian's post, it's really
> a situation of Dev1 _&_ Dev2 wrote this feature, but one of them
> happened to be typing and doing most of the nitty-gritty developing.
> Changing the authors between committs almost seems to introduce an
> arbitrary level of distinction where it's no longer _both_ but _one
> then the other_. Does that make my question any clearer?
FMPOV (and to follow the Pair Programming purpose), there isn't an "I"
in "Pair". So having the same author name and sign-off for each pair is
what makes most sense. IMHO, "dev1_and_dev2" is actually the best
option.
--
Nicolas Sebrecht
^ permalink raw reply
* Re: Direct ancestors from commit to HEAD
From: Jakub Narebski @ 2009-09-16 14:26 UTC (permalink / raw)
To: Gonsolo; +Cc: git
In-Reply-To: <4AB0EFC0.8020005@googlemail.com>
Gonsolo <gonsolo@gmail.com> writes:
> Is there a way to see only the direct line of (merge) ancestors from
> patch to HEAD? Something like:
>
> commit 0cb583fd2862f19ea88b02eb307d11c09e51e2f8
> Merge: 723e9db... a2d1056...
> Author: Linus Torvalds <torvalds@linux-foundation.org>
> Date: Tue Sep 15 10:01:16 2009 -0700
>
> Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6
>
> commit 88512935a24305fea7aecc9ba4d675869e97fc2a
> Merge: 8a62bab... 6b26dea...
> Author: David S. Miller <davem@davemloft.net>
> Date: Fri Aug 14 12:27:19 2009 -0700
>
> Merge branch 'master' of
> git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6
>
> commit edd7fc7003f31da48d06e215a93ea966a22c2a03
> Author: Nick Kossifidis <mick@madwifi-project.org>
> Date: Mon Aug 10 03:29:02 2009 +0300
>
> ath5k: Wakeup fixes
>
>
> Here I can see exactly how the ath5k patch came to mainline and since
> when it is there.
I don't know whether --first-parent or --simplify-by-decoration, or
perhaps --dense is what you want (you can also use --graph for better
visualization).
Or use git-show-branch... :-)
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Direct ancestors from commit to HEAD
From: Gonsolo @ 2009-09-16 15:10 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3vdjj2ceq.fsf@localhost.localdomain>
> I don't know whether --first-parent or --simplify-by-decoration, or
> perhaps --dense is what you want (you can also use --graph for better
> visualization).
Thank you. I think
git log --topo-order --dense --merges firstmerge..HEAD
comes very near. I still have to use "git log --topo-order", find the
commit of interest, and search upwards for the next merge that is used
as firstmerge above.
Unfortunately there are many merges in the net branch but it basically
does the job.
An example:
1. git log --topo-order, search for "Wakeup fixes" gives commit edd7fc.
2. Search backward for "^Merge" gives commit a8519d.
3. git log --topo-order --dense --merges edd7fc.., search for a8519d.
4. A search backwards for Linus gives you the merge into mainline: d7e966.
This commit is basically what I wanted to know. Even nicer would be a
three-commit-line only consisting of the merge into wireless, the merge
into net and the merge into mainline.
> Or use git-show-branch... :-)
I don't think I can use that since I have only a master branch sitting
around.
^ permalink raw reply
* [PATCH] Updated the usage string of git reset
From: Jan Stępień @ 2009-09-16 15:29 UTC (permalink / raw)
To: git, gitster; +Cc: Jan Stępień
Now the usage string reflects the behaviour of git reset and contents of
the man page.
Signed-off-by: Jan Stępień <jan@stepien.cc>
---
builtin-reset.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-reset.c b/builtin-reset.c
index 73e6022..78103ab 100644
--- a/builtin-reset.c
+++ b/builtin-reset.c
@@ -21,7 +21,7 @@
static const char * const git_reset_usage[] = {
"git reset [--mixed | --soft | --hard | --merge] [-q] [<commit>]",
- "git reset [--mixed] <commit> [--] <paths>...",
+ "git reset [-q] <commit> [--] <paths>...",
NULL
};
--
1.6.4.3
^ permalink raw reply related
* Re: [PATCH 04/15] Set _O_BINARY as default fmode for both MinGW and MSVC
From: Johannes Sixt @ 2009-09-16 16:14 UTC (permalink / raw)
To: Marius Storm-Olsen
Cc: git, Johannes.Schindelin, msysgit, gitster, j6t, lznuaa, raa.lkml,
snaury, Marius Storm-Olsen
In-Reply-To: <929c5a34cd2621af24bcda7e47ff2e76b51c2e09.1253088099.git.mstormo@gmail.com>
Marius Storm-Olsen schrieb:
> From: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
>
> MinGW set the _CRT_fmode to set both the default fmode and
> _O_BINARY on stdin/stdout/stderr. Rather use the main()
> define in mingw.h to set this for both MinGW and MSVC.
>
> This will ensure that a MinGW and MSVC build will handle
> input and output identically.
This one breaks t5302-pack-index.sh (test 15, "[index v1] 2) create a
stealth corruption in a delta base reference") in my MinGW build. I have
yet to find out what exactly goes wrong and how it could be fixed.
-- Hannes
^ permalink raw reply
* Re: [PATCH] Initial manually svn property setting support for git-svn
From: Thiago Farina @ 2009-09-16 16:18 UTC (permalink / raw)
To: David Fraser; +Cc: git, David Moore
In-Reply-To: <1927112650.1281253084529659.JavaMail.root@klofta.sjsoft.com>
On Wed, Sep 16, 2009 at 4:02 AM, David Fraser <davidf@sjsoft.com> wrote:
> This basically stores an attribute 'svn-properties' for each file that needs them changed, and then sets the properties when committing.
>
> Issues remaining:
> * The way it edits the .gitattributes file is suboptimal - it just appends to the end the latest version
> * It could use the existing code to get the current svn properties to see if properties need to be changed; but this doesn't work on add
> * It would be better to cache all the svn properties locally - this could be done automatically in .gitattributes but I'm not sure everyone would want this, etc
> * No support for deleting properties
>
> Usage is:
> git svn propset PROPNAME PROPVALUE PATH
>
> Added minimal documentation for git-svn propset
>
> Signed-off-by: David Fraser <davidf@sjsoft.com>
> ---
> Documentation/git-svn.txt | 5 ++
> git-svn.perl | 95 ++++++++++++++++++++++++++++++++++++++++++++-
> 2 files changed, 99 insertions(+), 1 deletions(-)
>
David, please read this, line 28:
http://git.kernel.org/?p=git/git.git;a=blob;f=Documentation/SubmittingPatches;h=76fc84d8780762e083cd4ca584b9d783b8c0cd81;hb=HEAD
Patches need to be send as plain text, not attached.
^ permalink raw reply
* [PATCH] push: Correctly initialize nonfastforward in do_push.
From: Matthieu Moy @ 2009-09-16 16:37 UTC (permalink / raw)
To: git, gitster; +Cc: Matthieu Moy
The variable is assigned unconditionally in print_push_status, but
print_push_status is not reached by all codepaths. In particular, this
fixes a bug where "git push ... nonexisting-branch" was complaining about
non-fast forward.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
(I'm the one to blame, sorry for introducing this bug)
builtin-push.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-push.c b/builtin-push.c
index 3cb1ee4..a73333b 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -140,7 +140,7 @@ static int do_push(const char *repo, int flags)
struct transport *transport =
transport_get(remote, url[i]);
int err;
- int nonfastforward;
+ int nonfastforward = 0;
if (receivepack)
transport_set_option(transport,
TRANS_OPT_RECEIVEPACK, receivepack);
--
1.6.5.rc1.11.g2d184.dirty
^ permalink raw reply related
* Re: git workflow for fully distributed mini-teams
From: Nicolas Sebrecht @ 2009-09-16 16:43 UTC (permalink / raw)
To: Rustom Mody; +Cc: Git Mailing List, Nicolas Sebrecht
In-Reply-To: <f46c52560909160035o6b09800eh5219d49e7569cf23@mail.gmail.com>
The 16/09/09, Rustom Mody wrote:
>
> A's best practices (and invariants) are:
> I (ie A) develop on dev (or other topic branches).
> I only merge onto master; never commit.
> I never work on nor merge onto B and C.
> When B sends me patches I apply them to the B branch likewise for C.
> Thereafter I merge that branch onto dev or master.
> There are no tracking branches because there are no remotes -- no
> central repo. [not clear about this]
>
> B and C have corresponding practices/behavior.
>
> So the questions...
>
> Is there a better way of doing things?
> Can some of these practices/invariants be enforced by scripts/options etc?
What's may be hard here is about "releasing topic". With a "maintainer
oriented workflow", the status of each topic is clear (either "won't
merge as is, needs more work" or "should be good enough, is merged and
aims to be in the next release").
In the fully-distributed workflow you describe, the state of the topics
looks hard to know. Who releases what is not clear.
Also, I see a duplication of the same work for all the developers in a
team: "merge my topics with topics from others". This could be solved
with one more common repository wich could stand as a "virtual
maintainer repository" where each developer could release any topic.
Topics that don't need any more work would have to be merged in a
dedicated public branch ("next"?) for testing, and topics that aren't
good enough into another dedicated branch ("pu"?). So, each developer
would have to push publishable merges into this repository. This way,
everyone could use the merges done by another developer (by doing a
fetch and rebasing of his current work on top of it).
Notice that this is all about "everybody uses the same base for his
current work" (to avoid per-developer scratch on merges) and "don't let
everyone do the same work on his own" (to avoid duplicate work).
> What about checkpointing and restoring from botches?
I think this is be easily doable (against your described workflow) with
good conventions in branch names. Topics like "pending-topicA",
"pending-topicB", etc that would have to be merged (using a script) into
a "all pending topics" branch should do what you want, no? Restoring
from botches would mean removing the crappy branch and re-execute the
script.
Hope this helps.
--
Nicolas Sebrecht
^ permalink raw reply
* Re: self contained executable
From: Alex Riesen @ 2009-09-16 16:44 UTC (permalink / raw)
To: Joel Saltzman; +Cc: Git Mailing List
In-Reply-To: <C3C630B6-7B54-42BE-9312-20BC20B7F051@gmail.com>
On Wed, Sep 16, 2009 at 18:36, Joel Saltzman <saltzmanjoelh@gmail.com> wrote:
> The last part is what I am trying to figure out. How do I set those linking
> flags?
Below, I assume you're a familiar with compilation.
Open Makefile and find the line "Platform specific tweaks".
That should be an example(s) for variables to set. Don't
mind the ifeq's.
Open config.mak and put there all the -I$$HOME/... and
-L$$HOME/... you need to reach the missing headers and
libraries. Your configuration will override the preset values.
That's almost it: you have to find out what exactly you're
missing on your own (for example, you may actually have
curl and openssl).
^ permalink raw reply
* Re: self contained executable
From: Matthieu Moy @ 2009-09-16 16:51 UTC (permalink / raw)
To: Joel Saltzman; +Cc: git
In-Reply-To: <ED42F58A-A814-467B-A37D-B485B2E267ED@gmail.com>
Joel Saltzman <saltzmanjoelh@gmail.com> writes:
> is it possible to compile git with all its dependencies so I can run
> it on a server that does not have root access?
Compiling with LDFLAGS='-static' is a first step, I'm not sure it's
sufficient.
But as Alex already pointed out, you don't have to be root to install
Git anyway (I'm using a git that I compiled myself, without being root
on my machine).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH] push: Correctly initialize nonfastforward in do_push.
From: Junio C Hamano @ 2009-09-16 17:13 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <1253119020-26547-1-git-send-email-Matthieu.Moy@imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> The variable is assigned unconditionally in print_push_status, but
> print_push_status is not reached by all codepaths. In particular, this
> fixes a bug where "git push ... nonexisting-branch" was complaining about
> non-fast forward.
Hmm, the patch looks correct but I am scratching my head to see how this
is triggered. "git push ... nonexisting-branch" seems to get:
error: src refspec nonexisting-branch does not match any.
error: failed to push some refs to '...'
^ permalink raw reply
* [PATCH v2] push: Correctly initialize nonfastforward in do_push.
From: Matthieu Moy @ 2009-09-16 17:28 UTC (permalink / raw)
To: git, gitster; +Cc: Matthieu Moy
In-Reply-To: <vpqfxamby33.fsf@bauges.imag.fr>
The variable is assigned unconditionally in print_push_status, but
print_push_status is not reached by all codepaths. In particular, this
fixes a bug where "git push ... nonexisting-branch" was complaining about
non-fast forward.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
New version initializing nonfastforward inside transport()
transport.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/transport.c b/transport.c
index 4cb8077..18db3d3 100644
--- a/transport.c
+++ b/transport.c
@@ -871,6 +871,7 @@ int transport_push(struct transport *transport,
int refspec_nr, const char **refspec, int flags,
int * nonfastforward)
{
+ *nonfastforward = 0;
verify_remote_names(refspec_nr, refspec);
if (transport->push)
--
1.6.5.rc1.11.g2d184.dirty
^ permalink raw reply related
* Re: [PATCH] push: Correctly initialize nonfastforward in do_push.
From: Matthieu Moy @ 2009-09-16 17:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpr9q24oa.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Matthieu Moy <Matthieu.Moy@imag.fr> writes:
>
>> The variable is assigned unconditionally in print_push_status, but
>> print_push_status is not reached by all codepaths. In particular, this
>> fixes a bug where "git push ... nonexisting-branch" was complaining about
>> non-fast forward.
>
> Hmm, the patch looks correct but I am scratching my head to see how this
> is triggered. "git push ... nonexisting-branch" seems to get:
Short answer: trust me, without the patch, you get the non-fast
forward (and valgrind tells you about conditional jump on
uninitialized value), with, you don't ;-).
Longer one:
int transport_push(struct transport *transport,
int refspec_nr, const char **refspec, int flags,
int * nonfastforward)
{
[...]
if (match_refs(local_refs, &remote_refs,
refspec_nr, refspec, match_flags)) {
return -1; /* <------------------------------ you stop here */
}
[...]
if (!quiet || push_had_errors(remote_refs))
print_push_status(transport->url, remote_refs,
verbose | porcelain, porcelain,
nonfastforward); /* <----- you would have updated nonfastforward there */
[...]
}
Actually, my initial version probably had the condition of the second
if too. And with the first "return" statement in transport_push.
Writting this, I'm wondering if it wouldn't be a better coding style
to initialize nonfastforward to 0 within transport_push (in case other
callers to transport_push appear one day, they won't get the the same
bug). Second version of the patch is comming.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox