* Re: Buggy (or undocumented) handling of terminal \r in .gitignore patterns
From: Michael J Gruber @ 2008-12-03 17:42 UTC (permalink / raw)
To: Aaron Harnly; +Cc: git
In-Reply-To: <loom.20081203T152511-351@post.gmane.org>
Aaron Harnly venit, vidit, dixit 03.12.2008 16:46:
> This is with git 1.5.6.3 on Ubuntu and Mac OS X.
>
> Overview: .gitignore patterns ending in \r do not work as expected, apparently
> because the terminal \r is assumed to be part of the newline.
>
> Steps to Reproduce:
> (NB ^M is the control-M sequence, not a literal caret-M)
>
> 1. Create an empty repository.
> 2. Create a file named Icon\r (aka Icon^M).
> 3. Add the following pattern to the .gitignore:
>
> Icon^M
>
> Expected behavior:
>
> The file is ignored.
>
> Actual behavior:
>
> The file is not ignored.
>
> Discussion:
>
> It appears that the parsing of .gitignore files tries to be graceful in allowing
> the file to have CRLF endings, or indeed mixed LF / CRLF endings.
>
> This is well and good, but poses a bit of a problem for ignoring files whose
> name ends in \r. In particular, Mac OS X's icon files are named Icon\r. Yes,
> this is sick and annoying on the part of Apple.
>
> I understand the rationale for this behavior, but it probably should be
> documented somewhere. In the meantime, a workaround that does allow the ignoring
> of these files is the pattern:
>
> Icon^M^M
>
> where again, the terminal \r seems to be ignored as part of the newline, but the
> penultimate \r gets picked up as part of the pattern.
>
> Any thoughts on whether:
> 1. this behavior should be left as it is
> 2. there is actually documentation somewhere that I didn't see
> 3. terminal \r in an otherwise all-LF file should be assumed to be part of the
> pattern
> 4. some other alternative?
5. spank Apple
^ permalink raw reply
* Re: Ad: fast-import problem importing dos format files under cygwin
From: Jan Hudec @ 2008-12-03 18:05 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Shawn O. Pearce, Johannes Sixt, git
In-Reply-To: <alpine.DEB.1.00.0812031718350.28112@intel-tinevez-2-302>
Hi,
On Wed, Dec 03, 2008 at 17:20:54 +0100, Johannes Schindelin wrote:
> Hi,
> On Wed, 3 Dec 2008, Shawn O. Pearce wrote:
> > Jan Hudec <bulb@ucw.cz> wrote:
> > > Dne 3 Prosinec 2008, 13:18, Johannes Sixt napsal(a):
> > > > Jan Hudec schrieb:
> > > >> On 3 December 2008, 08:51, Jan Hudec wrote:
> > > >>>
> > > >>> I have been playing with fast-import in cygwin and I have problems
> > > >>> importing files with CR/LF line-endings. The size in data command
> > > >>> is calculated including the CRs and than the file is copied binary
> > > >>> to the fast-import input stream. However fast-import skips the CRs
> > > >>> when reading, overreads by that number of bytes and fails when it
> > > >>> tries to read the next command from the middle.
> >
> > [...]
> > fast-import under-reading near CRs and getting misaligned on its input
> > indicates that the stdio library has given us a FILE* for stdin which is
> > converting CRLF pairs into LFs, even within an fread() call.
> >
> > My guess here is fast-import's stdin is set in text mode, but it really
> > needs to be in binary mode. fast-import.c never attempts to correct
> > that when it starts, so on DOS based systems we are probably totally
> > screwed from the beginning...
Yes, it does indeed sound so. Strange thing is why it would be that way, when
it does not seem to be the case for any other process (eg. the shell will
complain loudly if I feed it a DOS formatted script). The standard input is
simple shell redirect from a file on a binary-mounted filesystem. I'll do
some more cross-checks tomorrow.
> I think you need to set the environment variable
>
> CYGWIN=binmode
Will try. Thanks.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
^ permalink raw reply
* Re: Is there a way to control the number of revisions will be saved by git
From: Tzury Bar Yochay @ 2008-12-03 18:20 UTC (permalink / raw)
To: git
In-Reply-To: <2f5ea7490812030301p29e944fw5f59943dc352cd09@mail.gmail.com>
> Why would you want that, by the way?
I was thinking of building some experimental application on top of git
^ permalink raw reply
* Re: Is there a way to control the number of revisions will be saved by git
From: Tzury Bar Yochay @ 2008-12-03 18:23 UTC (permalink / raw)
To: git
In-Reply-To: <2f5ea7490812031020l57ec1a04x257c66549f3dac8a@mail.gmail.com>
On Wed, Dec 3, 2008 at 8:20 PM, Tzury Bar Yochay <tzury.by@gmail.com> wrote:
>> Why would you want that, by the way?
> I was thinking of building some experimental application on top of git
>
Looking at the numbers (of bytes). GIT's efficiency seems to redundant
this option which was a result of my concern about disk space usage.
GIT creators are magicians!
^ permalink raw reply
* [StGit PATCH] mail: add some commonly used tags to --auto
From: Dan Williams @ 2008-12-03 18:51 UTC (permalink / raw)
To: catalin.marinas; +Cc: git
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
---
stgit/commands/mail.py | 13 +++++++++++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/stgit/commands/mail.py b/stgit/commands/mail.py
index 72d0133..2dd88c3 100644
--- a/stgit/commands/mail.py
+++ b/stgit/commands/mail.py
@@ -283,8 +283,17 @@ def __get_signers_list(msg):
acked-by lines in the message.
"""
addr_list = []
-
- r = re.compile('^(signed-off-by|acked-by|cc):\s+(.+)$', re.I)
+ tags = '%s|%s|%s|%s|%s|%s|%s' % (
+ 'signed-off-by',
+ 'acked-by',
+ 'cc',
+ 'reviewed-by',
+ 'reported-by',
+ 'tested-by',
+ 'reported-and-tested-by')
+ regex = '^(%s):\s+(.+)$' % tags
+
+ r = re.compile(regex, re.I)
for line in msg.split('\n'):
m = r.match(line)
if m:
^ permalink raw reply related
* Re: git-p4 submit, Can't clobber writable file
From: Gary Yang @ 2008-12-03 19:06 UTC (permalink / raw)
To: Arafangion; +Cc: Jing Xue, git
In-Reply-To: <1228302466.23167.1.camel@therock.nsw.bigpond.net.au>
Arafangion,
I got email from Jing and I solved the problem. The doc should clearly state that we need a separated P4 working dir in order to make git p4 submit work. Many thanks to Jing.
Gary
--- On Wed, 12/3/08, Arafangion <thestar@fussycoder.id.au> wrote:
> From: Arafangion <thestar@fussycoder.id.au>
> Subject: Re: git-p4 submit, Can't clobber writable file
> To: garyyang6@yahoo.com
> Cc: "Jing Xue" <jingxue@digizenstudio.com>, git@vger.kernel.org
> Date: Wednesday, December 3, 2008, 3:07 AM
> I would argue that's a bug with git-p4, however that is
> a warning given
> by perforce, thus, you should be able to work around it by
> changing the
> clientspec, change the clientspec so that it will clobber
> such files,
> you will need to refer to the perforce docs for info about
> that.
>
> On Tue, 2008-12-02 at 22:04 -0800, Gary Yang wrote:
> > So, I have to keep two copies of source tree at my
> home directory. One is for Perforce build_scripts workspace,
> another is for Git build_scripts.git. I normally work at
> build_scripts.git. But, when I need to submit changes to
> Perforce, I have to copy changed code from build_scripts.git
> to build_scripts. Then, p4 submit code into Perforce. Is
> this the only way of using git-p4?
> > Note: I cannot use git-p4 submit at build_scripts. It
> claims "Cannot clobber writable file". Is it a bug
> of git-p4 or the instruction is not correct?
> >
> >
> > --- On Tue, 12/2/08, Jing Xue
> <jingxue@digizenstudio.com> wrote:
> >
> > > From: Jing Xue <jingxue@digizenstudio.com>
> > > Subject: Re: git-p4 submit, Can't clobber
> writable file
> > > To: "Gary Yang"
> <garyyang6@yahoo.com>
> > > Cc: git@vger.kernel.org
> > > Date: Tuesday, December 2, 2008, 7:07 PM
> > > On Tue, Dec 02, 2008 at 02:30:51PM -0800, Gary
> Yang wrote:
> > > >
> > > > I followed the instructions at
> > >
> http://modular.math.washington.edu/home/mhansen/git-1.5.5.1/contrib/fast-import/git-p4.txt
> > > >
> > > > But, I am not able to git-p4 submit. Any
> idea?
> > > >
> > > > git-p4 clone //build/scripts build_scripts
> > > > cd build_scripts
> > > > vi foo.h
> > > > git commit foo.h
> > > > git-p4 rebase
> > > > git-p4 submit
> > > >
> > > > from sets import Set;
> > > > Perforce checkout for depot path
> //build/scripts/
> > > located at /home/gyang/workspace/build_scripts/
> > > > Syncronizing p4 checkout...
> > > > //build/scripts/foo.h#1 - added as
> > > /home/gyang/workspace/build_scripts/foo.h
> > > > Can't clobber writable file
> > > /home/gyang/workspace/build_scripts/foo.h
> > > > //build/scripts/foo.c#1 - added as
> > > /home/gyang/workspace/build_scripts/foo.c
> > > > Can't clobber writable file
> > > /user/home/gyang/workspace/build_scripts/foo.c
> > > > ......
> > > > command failed: p4 sync ...
> > >
> > > You might want to clone to a git working dir
> different than
> > > the p4
> > > working dir.
> > >
> > > For instance, if your p4 workspace has the
> working dir set
> > > to
> > > build_scripts/, try 'git p4 clone
> //build/scripts
> > > build_scripts.git'.
> > >
> > > You would then normally work under
> build_scripts.git/.
> > > build_scripts/
> > > would only be used by git-p4 at submission time.
> > >
> > > Cheers.
> > > --
> > > Jing Xue
> >
> >
> >
> > --
> > To unsubscribe from this list: send the line
> "unsubscribe git" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at
> http://vger.kernel.org/majordomo-info.html
>
> --
> To unsubscribe from this list: send the line
> "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at
> http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [StGit PATCH] fix export -s
From: Dan Williams @ 2008-12-03 19:18 UTC (permalink / raw)
To: catalin.marinas; +Cc: git
Resolves:
stg export -s `stg top`
Traceback (most recent call last):
File "/usr/local/lib/python2.5/site-packages/stgit/main.py", line 152, in _main
ret = command.func(parser, options, args)
File "/usr/local/lib/python2.5/site-packages/stgit/commands/export.py", line 169, in func
f = sys.stdout
NameError: global name 'sys' is not defined
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
---
stgit/commands/export.py | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/stgit/commands/export.py b/stgit/commands/export.py
index dfdcea1..1236b01 100644
--- a/stgit/commands/export.py
+++ b/stgit/commands/export.py
@@ -19,6 +19,7 @@ Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
"""
import os
+import sys
from stgit.argparse import opt
from stgit.commands import common
from stgit import argparse, git, templates
^ permalink raw reply related
* Re: Problems with EGit
From: Robin Rosenberg @ 2008-12-03 19:21 UTC (permalink / raw)
To: Bastian Flinspach; +Cc: git
In-Reply-To: <4936689B.1030903@gerina.com>
onsdag 03 december 2008 12:08:11 skrev Bastian Flinspach:
Hi Bastian,
> When i try to commit changes via the command line, everything works fine
> (well, except for me not being able to use my keyboard right for
> entering the commit message, but thats probably not important because i
> want to use EGit anyways).
> Eclipse recognizes the repository and also displays changes i make. When
> trying to commit, however, i get a permission denied error.
>
> So, this is basically where i am stuck. What can be the problem and what
> would be a solution? I assume, that i might have something to do with
> Linux users and privileges, but i am not yet versed enough to identify
> the problem on my own.
If Git does not have permission problems, neither should EGit, I think, In the
workspace there is a file called .metadata/.log that you can inspect. See
if you can find anything interesting, i.e. a seemingly relevant stack trace or
other error message. The file can be quite large so try to cut it down.
> Please keep in mind, that i am a complete beginner with these topics
> when answering.
We all started at the beginning.
-- robin
^ permalink raw reply
* Re: Problems with EGit
From: Robin Rosenberg @ 2008-12-03 19:45 UTC (permalink / raw)
To: Bastian Flinspach; +Cc: git
In-Reply-To: <200812032021.57901.robin.rosenberg.lists@dewire.com>
onsdag 03 december 2008 20:21:57 skrev Robin Rosenberg:
> onsdag 03 december 2008 12:08:11 skrev Bastian Flinspach:
>
> Hi Bastian,
>
> > When i try to commit changes via the command line, everything works fine
> > (well, except for me not being able to use my keyboard right for
> > entering the commit message, but thats probably not important because i
> > want to use EGit anyways).
> > Eclipse recognizes the repository and also displays changes i make. When
> > trying to commit, however, i get a permission denied error.
> >
> > So, this is basically where i am stuck. What can be the problem and what
> > would be a solution? I assume, that i might have something to do with
> > Linux users and privileges, but i am not yet versed enough to identify
> > the problem on my own.
>
> If Git does not have permission problems, neither should EGit, I think, In the
> workspace there is a file called .metadata/.log that you can inspect. See
> if you can find anything interesting, i.e. a seemingly relevant stack trace or
> other error message. The file can be quite large so try to cut it down.
Starting eclipse from a shell, may yield even more information.
-- robin
^ permalink raw reply
* Re: [PATCH] git-svn: Make branch use correct svn-remote
From: Junio C Hamano @ 2008-12-03 20:06 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Git Mailing List, Eric Wong, Deskin Miller
In-Reply-To: <49365259.5090803@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
> Patch coming. (Sorry I always forget the ccs with send-email.)
Thanks, indeed my environment has svn 1.4.2 installed and Deskin's patch
with your patch squashed in makes everything happy again.
^ permalink raw reply
* Re: summaries in git add --patch[PATCH 1/2]
From: William Pursell @ 2008-12-03 20:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vskp6j95x.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> One thing I will not do after such a discussion, unless I am really really
> interested in having the new feature personally myself, is to go back to
> the discussion thread and assemble the pieces together to make the final
> series of patches for inclusion. The responsibility for doing that lies
> on the original contributor.
>
That is a perfectly reasonable policy, and I did not intend
to suggest that you should do that work. My apologies if
it seemed that way. Here is the first of 2 patches to
implement the 'g' command. I believe it is complete, but
I am not much for user interface. It works for me, but it
could be improved upon. (For example, I took your suggestion
and disallowed 'g' when there is only one hunk, but the
behavior feels clunky, although it is similar to an invalid
k/j entry.)
From de169b0062ae21f085d1309b4dd7da369029ae7d Mon Sep 17 00:00:00 2001
From: William Pursell <bill.pursell@gmail.com>
Date: Wed, 3 Dec 2008 20:25:31 +0000
Subject: [PATCH 1/2] Add subroutine to display one-line summary of hunks.
This commit implements a rather simple-minded mechanism
to display a one-line summary of the hunks in an array ref.
The display consists of the line numbers and the first
changed line, truncated to 80 characters. 20 lines are
displayed at a time, and the index of the first undisplayed
line is returned, allowing the caller to display more if
desired. (The 20 and 80 should be made configurable.)
Signed-off-by: William Pursell <bill.pursell@gmail.com>
---
git-add--interactive.perl | 39 +++++++++++++++++++++++++++++++++++++++
1 files changed, 39 insertions(+), 0 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index b0223c3..daf8d5d 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -836,6 +836,45 @@ sub patch_update_cmd {
}
}
+# Generate a one line summary of a hunk.
+sub summarize_hunk {
+ my $rhunk = shift;
+ my $summary = $rhunk->{TEXT}[0];
+
+ # Keep the line numbers, discard extra context.
+ $summary =~ s/(@@.*@@).*/$1 /s;
+
+ # Add some user context. (Just take first changed line.)
+ for my $line (@{$rhunk->{TEXT}}) {
+ if ($line =~ m/^[+-]/) {
+ $summary .= $line;
+ last;
+ }
+ }
+
+ return substr ($summary, 0, 80);
+}
+
+
+# Print a one-line summary of each hunk in the array ref in
+# the first argument, starting wih the index in the 2nd.
+sub display_hunks {
+ my ($hunks, $i) = @_;
+ my $ctr = 0;
+ $i = 0 if not $i;
+ for (; $i < @$hunks && $ctr < 20; $i++, $ctr++) {
+ my $status = " ";
+ if (defined $hunks->[$i]{USE}) {
+ $status = $hunks->[$i]{USE} ? "+" : "-";
+ }
+ printf "%s%2d: %s",
+ $status,
+ $i + 1,
+ summarize_hunk ($hunks->[$i]);
+ }
+ return $i;
+}
+
sub patch_update_file {
my ($ix, $num);
my $path = shift;
--
1.6.1.rc1.37.g83daf.dirty
--
William Pursell
^ permalink raw reply related
* Re: summaries in git add --patch[PATCH 2/2]
From: William Pursell @ 2008-12-03 20:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vskp6j95x.fsf@gitster.siamese.dyndns.org>
From 57b5eab3f64a40ebe9aca122b5c6db1ab5c26116 Mon Sep 17 00:00:00 2001
From: William Pursell <bill.pursell@gmail.com>
Date: Wed, 3 Dec 2008 20:26:36 +0000
Subject: [PATCH 2/2] Implemented 'g' command to goto a hunk.
When a minor change is made while the working directory
is in a bit of a mess (and the user should have done a
stash before making the minor edit, but didn't) it is
somewhat difficult to wade through all of the hunks using
git add --patch. This allows one to jump to the hunk
that needs to be staged without having to respond 'n' to
each preceding hunk.
Signed-off-by: William Pursell <bill.pursell@gmail.com>
---
git-add--interactive.perl | 25 +++++++++++++++++++++++++
1 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index daf8d5d..98ce8e3 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -800,6 +800,7 @@ y - stage this hunk
n - do not stage this hunk
a - stage this and all the remaining hunks in the file
d - do not stage this hunk nor any of the remaining hunks in the file
+g - select a hunk to goto
j - leave this hunk undecided, see next undecided hunk
J - leave this hunk undecided, see next hunk
k - leave this hunk undecided, see previous undecided hunk
@@ -943,6 +944,9 @@ sub patch_update_file {
if ($ix < $num - 1) {
$other .= '/J';
}
+ if ($num > 1) {
+ $other .= '/g';
+ }
for ($i = 0; $i < $num; $i++) {
if (!defined $hunk[$i]{USE}) {
$undecided = 1;
@@ -976,6 +980,27 @@ sub patch_update_file {
}
next;
}
+ elsif ($other =~ 'g' && $line =~ /^g(.*)/) {
+ my $response = $1;
+ my $i = 0;
+ chomp $response;
+ while (not $response) {
+ my $extra = "";
+ $i = display_hunks (\@hunk, $i);
+ $extra = "(<ret> to see more): " if ($i != $num);
+ print "goto which hunk? $extra";
+ $response = <STDIN>;
+ chomp $response;
+ }
+ if ($response !~ /^\s*\d+$/) {
+ print STDERR "Invalid number: '$response'\n";
+ } elsif (0 < $response && $response <= $num) {
+ $ix = $response - 1;
+ } else {
+ print STDERR "Sorry, only $num hunks available.\n";
+ }
+ next;
+ }
elsif ($line =~ /^d/i) {
while ($ix < $num) {
if (!defined $hunk[$ix]{USE}) {
--
1.6.1.rc1.37.g83daf.dirty
--
William Pursell
^ permalink raw reply related
* Re: [PATCH] git-svn: Make branch use correct svn-remote
From: Deskin Miller @ 2008-12-03 20:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael J Gruber, Git Mailing List, Eric Wong
In-Reply-To: <7v1vwpdnwy.fsf@gitster.siamese.dyndns.org>
On Wed, Dec 03, 2008 at 12:06:05PM -0800, Junio C Hamano wrote:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
>
> > Patch coming. (Sorry I always forget the ccs with send-email.)
>
> Thanks, indeed my environment has svn 1.4.2 installed and Deskin's patch
> with your patch squashed in makes everything happy again.
Ah, curse my trusting svn to work the same between versions, and not
testing on 1.4. Thanks for the quick fix, Michael.
Deskin Miller
^ permalink raw reply
* Re: [RFCv2 1/2] gitweb: add patch view
From: Giuseppe Bilotta @ 2008-12-03 20:52 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git, Petr Baudis
In-Reply-To: <200812031808.01916.jnareb@gmail.com>
On Wed, Dec 3, 2008 at 6:08 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Wed, Dec 3, 2008 at 14:14, Giuseppe Bilotta wrote:
>>
>> The way it's implemented in v2, you just need to set $patch_max in
>> your local or system config file (e.g. /etc/gitweb.conf). I'm not sure
>> about the benefit we would gain in going through %feature.
>
> Ah, I haven't read patch in detail yet.
>
> The (doubtful or not) benefit of going through %feature would be ability
> to set limits (with perhaps -1 / <0 / undef / '' meaning: unlimited) on
> per repository basis, with no limit for small repository, some limit for
> the rest, and no 'patch' view or heavily limited for repository with
> large size commits.
Hm. I'm not entirely sure it would be used at all, but I think this
could be done. Something like the following:
* perl false meaning: feature disabled
* > 0 maximum number of patches
* does Perl have an 'infinity' value? if not, we can use <0 to mean unlimited
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* gitk: 'show origin of this line' barfs if gitk run in subdir
From: Mark Burton @ 2008-12-03 20:51 UTC (permalink / raw)
To: Git Mailing List; +Cc: Paul Mackerras
Hi,
I was just trying out the new gitk feature that shows you the origin of a
selected line in the diff pane and found that it doesn't work right if
gitk is not started in the top-level work directory - i.e. if you are
in a subdir it pops up an error message of this form:
Error running git blame: fatal: no such path $path in $sha1
I guess it needs something like subdir-depth number of ../ prepended to
the front of the pathname to make the blame succeed.
I could try and fix this but I am sure that others who understand
the sources of gitk/git-blame/git can do it much quicker than me.
Cheers,
Mark
^ permalink raw reply
* Re: [PATCH] Implement rebase -q to fix pull --rebase -q
From: Junio C Hamano @ 2008-12-03 21:14 UTC (permalink / raw)
To: Tuncer Ayaz; +Cc: git
In-Reply-To: <4ac8254d0812030035n52fde4b3s29c0f525e175f123@mail.gmail.com>
"Tuncer Ayaz" <tuncer.ayaz@gmail.com> writes:
> On Wed, Dec 3, 2008 at 9:26 AM, Junio C Hamano <gitster@pobox.com> wrote:
> ...
>> Ahh, ok, if this is for cron jobs, then it is understandable that:
>>
>> (1) You may want a successful "git pull" or "git pull --rebase" to be
>> absolutely silent about what it did; and
>>
>> (2) A failed "git pull" and "git pull --rebase" that produces information
>> other than the fact it failed would not help you, the receiver of a
>> cron job report, very much. You would go to the repository when it
>> fails, reset the mess away, and then do the pull or pull-rebase
>> yourself manually anyway.
>>
>> If that is the motivation behind the series, I think you would really want
>> to squelch output from "format-patch | am -3" pipeline.
>
> You mean I should follow this path and produce a patch series instead?
Not necessarily. It is entirely up to you.
An important point at this point is that the patch as submitted, without
such a change, will not be useful to achieve the goal (1) above, because
it will still be chatty.
>> would be driving "git pull" from a cron job. IOW, you probably would want
>> something like "--really-quiet" mode.
>
> Yeah, it gets messy and in the current codebase. I am also not sure whether
> the effort/benefit ratio is good enough.
I doubt "the current codebase" has more downside than upside as you seem
to imply. The way rebase uses layered set of other commands keeps the
door open to spread the benefits around. If you squelch format-patch, you
would help people who would want to drive it from their cron job (perhaps
they are on dial-up and they would rather batch things up than running
format-patch and send-email from their post-receive hook). If you squelch
am, you would help people who use it as a part of their mailing list
scanning software that runs unattended. Of course, you could choose to
squelch the "format-patch | am -3" pipeline in one go by redirecting the
entire pipe to somewhere, instead of giving individual commands --quiet
option. If you did so, obviously the benefits won't be spread to users of
these underlying commands.
But I do not think squelching of these individual commands such as
format-patch, am, and pull are so useful in the larger picture in the
context of scripting; see below.
>> I would write such a cron-job script to capture the log and send it only
>> upon failure from the underlying command if I were doing this myself,
>> though.
>
> This is the way I do it now and I'm surprised I found no other simple way
> than writing a wrapper script for it. At least not with vixie-cron.
Actually I am not so surprised.
A cron job that contains a git pull most likely needs to be a script that
wants to do many other things anyway, such as chdir into the target
repository, make sure nobody (including yourself) did not by mistake went
into the repository and made local changes that may interfere with the
pull and if so abort, perform the pull, noticing its exit status, produce
the error report and exit if pull fails, validate each new commits the
pull brought in against some in-house coding standard, run a build test
(perhaps "make test") if pull succeeded, noticing its exit status, produce
the error report and exit if the build fails, install the build result if
build succeeded, and so on. Individual steps such as "git pull" and "make
install" are only small self-contained building blocks in such a workflow,
and it is not unusual for such a script to redirect output from the
building blocks it uses and produce a summarized report at the very end of
the run using the redirected output, while emitting messages on its own.
In such an arrangement, having "a bit quieter than usual" option in the
underlying command, which would be what we would want for these primarily
interactive commands, is not very useful anyway, because the "quieter"
output mode may drop some information you might want to include in the
fuller report when something goes wrong, and filtering such "a bit
quieter" output takes as much effort as filtering the output from the
normal mode when there is nothing noteworthy to report and your script
wants to squelch the output entirely.
^ permalink raw reply
* Re: [PATCH] gitweb: Fix handling of non-ASCII characters in inserted HTML files
From: Junio C Hamano @ 2008-12-03 21:14 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Tatsuki Sugiura, Gerrit Pape, Recai Oktas
In-Reply-To: <200812031121.43606.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> With "close $fd" removed the patch is correct (and patches t9500*).
Yeah, it passes that test here, too. Let's unleash it to 'master' and in
an unlikely case where it still has bugs we know which commit to revert
;-).
Thanks.
^ permalink raw reply
* Re: [PATCH] gitweb: Optional grouping of projects by category
From: Junio C Hamano @ 2008-12-03 21:14 UTC (permalink / raw)
To: Jakub Narebski
Cc: Sebastien Cevey, git, Petr Baudis, Gustavo Sverzut Barbieri
In-Reply-To: <200812030036.13562.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> On Tue, 2 Dec 2008, Sebastien Cevey wrote:
> ...
>> I submitted a previous version of this patch on July 27, but was told
>> to wait for the end of the feature freeze. I submitted it again on
>> September 5, but didn't get any reply. Hope to be luckier this time!
>
> Unfortunately it looks like you hit the edge of feature freeze again.
Freeze for 1.6.1 by itself does not have to stop you or anybody to review
the patch and Ack for queuing for 'next' ;-)
^ permalink raw reply
* Re: more merge strategies : feature request
From: Nanako Shiraishi @ 2008-12-03 21:27 UTC (permalink / raw)
To: Leo Razoumov; +Cc: Caleb Cushing, git
In-Reply-To: <ee2a733e0812021707i82049eai866035aef3386264@mail.gmail.com>
Quoting "Leo Razoumov" <slonik.az@gmail.com>:
> On 12/2/08, Caleb Cushing <xenoterracide@gmail.com> wrote:
>> > I guess that "no-overwrite" can be achieved by
>> >
>> > git merge -s ours --no-commit
>>
>> no it doesn't. which is why I called it a bad name. no-overwrite would
>> still add new lines to the file not in ours (and no-commit isn't
>> needed in that case) it just wouldn't overwrite conflicting lines, my
>> understanding of ours is that it will keep the files as is.
Isn't what Caleb wants "-X ours/theirs" per-hunk option for merge strategy backends?
It was discussed several months ago on the list and was rejected. For details you can start here:
http://thread.gmane.org/gmane.comp.version-control.git/89010/focus=89021
I still think the patch in the above link was reasonable, but the thread was distracted into discussing minor syntactical details of how the option gets passed to the backend, and the rest of the discussion to decide if it makes sense to add such a feature was unfortunately lost in the noise and never concluded.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* [StGit PATCH] Print conflict details with the new infrastructure (bug #11181)
From: Catalin Marinas @ 2008-12-03 21:38 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
The patch modifies the IndexAndWorkTree.merge() function to display
pass the conflict information (files) when raising an exception. The
logic is similar to the one in the old infrastructure.
Signed-off-by: Catalin Marinas <catalin.marinas@gmail.com>
---
stgit/lib/git.py | 15 ++++++++++-----
stgit/lib/transaction.py | 11 ++++++++---
2 files changed, 18 insertions(+), 8 deletions(-)
diff --git a/stgit/lib/git.py b/stgit/lib/git.py
index 0a208ef..e2b4266 100644
--- a/stgit/lib/git.py
+++ b/stgit/lib/git.py
@@ -677,6 +677,9 @@ class MergeException(exception.StgException):
class MergeConflictException(MergeException):
"""Exception raised when a merge fails due to conflicts."""
+ def __init__(self, conflicts):
+ MergeException.__init__(self)
+ self.conflicts = conflicts
class Index(RunWithEnv):
"""Represents a git index file."""
@@ -829,12 +832,14 @@ class IndexAndWorktree(RunWithEnvCwd):
env = { 'GITHEAD_%s' % base.sha1: 'ancestor',
'GITHEAD_%s' % ours.sha1: 'current',
'GITHEAD_%s' % theirs.sha1: 'patched'})
- r.discard_output()
+ r.returns([0, 1])
+ output = r.output_lines()
+ if r.exitcode:
+ # There were conflicts
+ conflicts = [l for l in output if l.startswith('CONFLICT')]
+ raise MergeConflictException(conflicts)
except run.RunException, e:
- if r.exitcode == 1:
- raise MergeConflictException()
- else:
- raise MergeException('Index/worktree dirty')
+ raise MergeException('Index/worktree dirty')
def changed_files(self, tree, pathlimits = []):
"""Return the set of files in the worktree that have changed with
respect to C{tree}. The listing is optionally restricted to
diff --git a/stgit/lib/transaction.py b/stgit/lib/transaction.py
index 0f414d8..54de127 100644
--- a/stgit/lib/transaction.py
+++ b/stgit/lib/transaction.py
@@ -94,6 +94,7 @@ class StackTransaction(object):
self.__base = self.__stack.base
self.__discard_changes = discard_changes
self.__bad_head = None
+ self.__conflicts = None
if isinstance(allow_conflicts, bool):
self.__allow_conflicts = lambda trans: allow_conflicts
else:
@@ -201,7 +202,10 @@ class StackTransaction(object):
self.__stack.set_head(new_head, self.__msg)
if self.__error:
- out.error(self.__error)
+ if self.__conflicts:
+ out.error(*([self.__error] + self.__conflicts))
+ else:
+ out.error(self.__error)
# Write patches.
def write(msg):
@@ -311,9 +315,10 @@ class StackTransaction(object):
tree = iw.index.write_tree()
self.__current_tree = tree
s = ' (modified)'
- except git.MergeConflictException:
+ except git.MergeConflictException, e:
tree = ours
merge_conflict = True
+ self.__conflicts = e.conflicts
s = ' (conflict)'
except git.MergeException, e:
self.__halt(str(e))
@@ -344,7 +349,7 @@ class StackTransaction(object):
# Save this update so that we can run it a little later.
self.__conflicting_push = update
- self.__halt('Merge conflict')
+ self.__halt("%d merge conflict(s)" % len(self.__conflicts))
else:
# Update immediately.
update()
^ permalink raw reply related
* Re: [PATCH] Implement rebase -q to fix pull --rebase -q
From: Tuncer Ayaz @ 2008-12-03 22:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vljuxc672.fsf@gitster.siamese.dyndns.org>
On Wed, Dec 3, 2008 at 10:14 PM, Junio C Hamano <gitster@pobox.com> wrote:
> "Tuncer Ayaz" <tuncer.ayaz@gmail.com> writes:
>
>> On Wed, Dec 3, 2008 at 9:26 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> ...
>>> Ahh, ok, if this is for cron jobs, then it is understandable that:
>>>
>>> (1) You may want a successful "git pull" or "git pull --rebase" to be
>>> absolutely silent about what it did; and
>>>
>>> (2) A failed "git pull" and "git pull --rebase" that produces information
>>> other than the fact it failed would not help you, the receiver of a
>>> cron job report, very much. You would go to the repository when it
>>> fails, reset the mess away, and then do the pull or pull-rebase
>>> yourself manually anyway.
>>>
>>> If that is the motivation behind the series, I think you would really want
>>> to squelch output from "format-patch | am -3" pipeline.
>>
>> You mean I should follow this path and produce a patch series instead?
>
> Not necessarily. It is entirely up to you.
>
> An important point at this point is that the patch as submitted, without
> such a change, will not be useful to achieve the goal (1) above, because
> it will still be chatty.
I personally don't see a huge point right now in implementing -q
in any more commands.
>>> would be driving "git pull" from a cron job. IOW, you probably would want
>>> something like "--really-quiet" mode.
>>
>> Yeah, it gets messy and in the current codebase. I am also not sure whether
>> the effort/benefit ratio is good enough.
>
> I doubt "the current codebase" has more downside than upside as you seem
> to imply. The way rebase uses layered set of other commands keeps the
I think it gets "messy" if you start implementing more and more
log levels without an internal consistent logging API. That's
all I wanted to imply :). And this last statement does not
imply that we need such an API. I'm not so sure anymore and
prefer to not work on it without a good plan.
> door open to spread the benefits around. If you squelch format-patch, you
> would help people who would want to drive it from their cron job (perhaps
> they are on dial-up and they would rather batch things up than running
> format-patch and send-email from their post-receive hook). If you squelch
> am, you would help people who use it as a part of their mailing list
> scanning software that runs unattended. Of course, you could choose to
> squelch the "format-patch | am -3" pipeline in one go by redirecting the
> entire pipe to somewhere, instead of giving individual commands --quiet
> option. If you did so, obviously the benefits won't be spread to users of
> these underlying commands.
>
> But I do not think squelching of these individual commands such as
> format-patch, am, and pull are so useful in the larger picture in the
> context of scripting; see below.
>
>>> I would write such a cron-job script to capture the log and send it only
>>> upon failure from the underlying command if I were doing this myself,
>>> though.
>>
>> This is the way I do it now and I'm surprised I found no other simple way
>> than writing a wrapper script for it. At least not with vixie-cron.
>
> Actually I am not so surprised.
My script is trivial.
It executes the command supplied, captures stderr and stdout to a
temporary file and if and only if the command does not return a
success code the contents of the file are echoed and this leads to
cron mailing the output.
> A cron job that contains a git pull most likely needs to be a script that
> wants to do many other things anyway, such as chdir into the target
> repository, make sure nobody (including yourself) did not by mistake went
> into the repository and made local changes that may interfere with the
> pull and if so abort, perform the pull, noticing its exit status, produce
> the error report and exit if pull fails, validate each new commits the
> pull brought in against some in-house coding standard, run a build test
> (perhaps "make test") if pull succeeded, noticing its exit status, produce
> the error report and exit if the build fails, install the build result if
> build succeeded, and so on. Individual steps such as "git pull" and "make
> install" are only small self-contained building blocks in such a workflow,
> and it is not unusual for such a script to redirect output from the
> building blocks it uses and produce a summarized report at the very end of
> the run using the redirected output, while emitting messages on its own.
>
> In such an arrangement, having "a bit quieter than usual" option in the
> underlying command, which would be what we would want for these primarily
> interactive commands, is not very useful anyway, because the "quieter"
> output mode may drop some information you might want to include in the
> fuller report when something goes wrong, and filtering such "a bit
> quieter" output takes as much effort as filtering the output from the
> normal mode when there is nothing noteworthy to report and your script
> wants to squelch the output entirely.
>
ACK.
^ permalink raw reply
* Re: Add 'sane' mode to 'git reset'
From: Junio C Hamano @ 2008-12-03 22:22 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0812010908120.3256@nehalem.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> We have always had a nice way to reset a working tree to another state
> while carrying our changes around: "git read-tree -u -m". Yes, it fails if
> the target tree is different in the paths that are dirty in the working
> tree, but this is how we used to switch branches in "git checkout", and it
> worked fine.
>
> However, perhaps exactly _because_ we've supported this from very early
> on, another low-level command, namely "git reset", never did.
>
> But as time went on, 'git reset' remains as a very common command, while
> 'git read-tree' is now a very odd and low-level plumbing thing that nobody
> sane should ever use, because it only makes sense together with other
> operations like either switching branches or just rewriting HEAD.
>
> Which means that we have effectively lost the ability to do something very
> common: jump to another point in time without always dropping all our
> dirty state.
> ...
> I've wanted this for a long time, since I very commonly carry a dirty
> tree while working on things. My main 'Makefile' file quite often has the
> next version already modified, and sometimes I have local modifications
> that I don't want to commit, but I still do pulls and patch applications,
> and occasionally want to do "git reset" to undo them - while still keeping
> my local modifications.
I think a bit more explicit description with an example command sequence
in the documentation is in order. Here is what I managed to reconstruct
from your description.
Let's say you have a small change in the Makefile and some other local
changes that you would want to keep uncommitted. Then you receive a
pull request that you would want to respond to. So you do this:
$ git pull $URL $branch
knowing that your own local changes will be safe because pull will
refuse to clobber them if the changes in the other person did overlaps
with it. Let's further say that the changes did not overlap, the
merge succeeded and you still have your own local changes.
But after inspecting the result, you realize that you do not want this
change after all. That means rewinding the HEAD back to the previous
point (i.e. ORIG_HEAD), match the index to that commit, *and* rewind
the work tree back to the state before the merge (i.e. mostly matching
the index except for the local changes to Makefile and a handful other
files). "git reset" is the command to move the HEAD. What mode
should you use?
Unfortunately, the only two modes that touch the index and/or the work
tree are --mixed and --hard.
You do not want to use --hard, because it will discard your local
changes. You do not want to use --mixed either, because it will keep
not just your local changes but also the changes the merge brought
into your work tree. That's when you would want to use --merge mode.
$ git reset --merge ORIG_HEAD
This command (1) resets the HEAD to the given commit (ORIG_HEAD in
this example), and runs "read-tree -m -u HEAD ORIG_HEAD" which means
(2) resets the index to match the tree recorded by that commit, and
(3) updates the files in the work tree for difference between HEAD and
ORIG_HEAD, i.e. undoing the changes made between ORIG_HEAD and HEAD.
Because you know the work undone in (3) does not overlap with your
local changes, this is exactly what you want in such a situation.
This procedure works just as well when you are accepting patches by
replacing "git pull" with "git am" and "ORIG_HEAD" with "HEAD~$n"
(where $n is the number of patches contained in the e-mailed series)
in the above description.
Does the above describe what you meant?
Although I admit that I have used "read-tree -m -u" for probably more than
a couple of times in the past 6 months, I really do not recall the exact
sequence that led me into the situation where it was the most appropriate
command to use. I do not think any of these occassions were about me
having a wrong commit at HEAD (meaning, I really wanted to read the index
and update the work tree, without changing where the next commit would
go), so obviously my workflow is quite different from yours.
The recovery procedure I would use in such a case (and I rarely pull while
managing git.git even though I do so in my day job) would be:
$ git checkout -b this-needs-more-work
$ git checkout master
to stash away the "topic" that needs more work in a new branch, and have
"checkout" take me back to where I was with my local modifications, and
that is probably why I never felt the need for this new mode (nor did not
understand why you thought very strongly that --merge should be the
default mode and not --mixed).
^ permalink raw reply
* Re: gitk: 'show origin of this line' barfs if gitk run in subdir
From: Mark Burton @ 2008-12-03 22:22 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Git Mailing List
In-Reply-To: <20081203205158.6b4b62c7@crow>
Hi,
I think the same problem exists with the 'run git gui blame on this
line' feature. It doesn't work when gitk is started in a subdir of the
working tree but it does work when gitk is started in the top-level
directory.
Cheers,
Mark
^ permalink raw reply
* read-only mode
From: jidanni @ 2008-12-03 22:44 UTC (permalink / raw)
To: git
Here's a documentation stub. Please fix and finish it and place in some manual.
==Using git in read-only mode==
Let's say you just want to examine things. There is a fine line
between commands and options that just examine things vs. those that
change things. One might worry that they can't remember that fine line.
Therefore the safest way to ensure you are using git in 'read-only mode' is to
* su nobody, or
* chmod -R u-w . (and remember to chmod -R u+w when you are finished), or
* ???
^ permalink raw reply
* Re: [PATCH v2] gitweb: Optional grouping of projects by category
From: Junio C Hamano @ 2008-12-03 22:51 UTC (permalink / raw)
To: Sébastien Cevey
Cc: Jakub Narebski, git, Petr Baudis, Gustavo Sverzut Barbieri
In-Reply-To: <87prk91got.wl%seb@cine7.net>
Sébastien Cevey <seb@cine7.net> writes:
> This adds the $projects_list_group_categories option which, if enabled,
> will result in grouping projects by category on the project list page.
> The category is specified for each project by the $GIT_DIR/category file
> or the 'category' variable in its configuration file. By default, projects
> are put in the $project_list_default_category category.
>
> Note:
> - Categories are always sorted alphabetically, with projects in
> each category sorted according to the globally selected $order.
I am not sure if always sorting the categories alphabetically is a severe
enough restriction, but if it was, you can use @project_list_categories
array that disables the feature when empty and otherwise enumerates the
categories in order. Just an idle thought.
> - When displaying a subset of all the projects, only the categories with
> projects in the chosen subset are displayed.
Could you clarify this bit?
It is not very clear to me how this subset selection happens. As far as I
can see, the user does not choose the category to view, but lets the usual
page limiting to decide at which project to start and stop placing on the
page, and only show the ones in the same category as the one that happened
to be the first on the page.
While I think both the introduction of "git_get_project_config_or_file"
which is a generalized interface usable between description and the new
feature and the refactoring of project_list_body into a seprate function
"print_project_rows" is a good idea, the patch would have been much easier
to read if these preparatory refactoring steps (without any new feature)
were done as a separate patch followed by the main patch to introduce the
new feature.
^ 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