* Re: [PATCH/RFC] Use regex for :/ matching
From: Junio C Hamano @ 2007-12-03 18:17 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, git
In-Reply-To: <20071203173022.GA19219@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Mon, Dec 03, 2007 at 10:55:15AM +0000, Johannes Schindelin wrote:
>
>> Except that I did not support ".." (does yours?), _and_ that my patch is
>> not as nice as yours.
>
> No, I didn't. I'm not sure it is sane, since :/ can contain free-form
> text (and with a regex, .. is not that unlikely). And you can always do
> git-log --not :/foo :/bar
>
>> But then, my patch also works when save_commit_buffer == 0. But I can
>> refactor this into its own patch, since it really is a separate issue.
>
> Agreed.
What I found mildly irritating in the current syntax (and that is the
primary reason why I use it rarely) is that there is no way to tell it
to dig from a particular ref (e.g. "on master branch, find the latest
commit whose title matches this string").
For "git-log", you can do "git log master --grep=string -1" to emulate
this, and it extends to "git log maint..master --grep=string" to limit
the revision ranges and "find all not just latest" very naturally.
Also once we start to talk about supporting "ranges", I suspect the
semantics becomes fuzzier, because ":/" is defined as an extended SHA-1
expression that resolves to a single commit. ":/A..:/B" is probably
unneeded as you can always say "^:/B :/A", but making ":/A" (we need an
extended syntax to differentiate from the singleton case we currently
have) to mean "all the commits that match this pattern" is something
people might be interested to see. Unfortunately, that does not define
a revision range operator but a operator that gives back set of commits
that are not consecutive, primarily good for giving to nothing but "git
show", and again "git log --grep" would emulate it just as well.
So in short:
* I do not think extending it to mean a set of commits (with some
definition of how the set is computed) is a good idea. It can stay
"name one commit that matches this string" without losing usefulness,
and I think it should;
* The definition of the "match" can be tweaked and introducing regexp
might be a good way;
* The definition of the "match" may become more useful if we can limit
which refs to dig from.
^ permalink raw reply
* Re: [PATCH] git-commit --allow-empty
From: Junio C Hamano @ 2007-12-03 18:16 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Mark Drago, stelian, git
In-Reply-To: <alpine.LFD.0.99999.0712031255560.9605@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> On Mon, 3 Dec 2007, Junio C Hamano wrote:
>
>> +--allow-empty::
>> + Usually recording a commit that has the exact same tree as its
>> + sole parent commit and the command prevents you from making such
>> + a mistake. This option bypasses the safety, and is primarily
>> + for use by foreign scm interface scripts.
>
> The first sentence is rather buggy I would say.
It indeed is. Sorry.
^ permalink raw reply
* Re: [REGRESSION ?] git-remote "--mirror" option is not integrated in 1.5.3.7
From: Junio C Hamano @ 2007-12-03 18:09 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Felipe Balbi, git
In-Reply-To: <Pine.LNX.4.64.0712031622470.27959@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Mon, 3 Dec 2007, Felipe Balbi wrote:
>
>> I've using git-remote --mirror mode for while right now but I saw it's
>> not integrated in v.1.5.3.7, is this on purpose? I can still get it if I
>> compile recent git's head "36863af16e91aebc87696209f4f4780cf4c4059f".
>
> AFAICT there are problems with --prune. That might be a reason that it is
> not in 1.5.3.7 (haven't checked if that's even the case, though).
That is a _NEW_ feature. Maintenance series won't get any new features.
^ permalink raw reply
* Re: Incorrect git-blame result if I use full path to file
From: Johannes Schindelin @ 2007-12-03 18:09 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Anatol Pomozov, git
In-Reply-To: <alpine.LFD.0.9999.0712030922250.8458@woody.linux-foundation.org>
Hi,
On Mon, 3 Dec 2007, Linus Torvalds wrote:
> It [the patch] makes "get_pathspec()" make all the paths it returns
> relative, if it can. HOWEVER! I think it should actually die() if it
> sees an absolute path that it cannot convert (because it really cannot
> do anything sane about it), but I commented that out for now because
> that requires some test case change: right now we actually have a few
> test cases for insane filename arguments, and they expect the old
> behaviour.
I have the slight suspicion that this could break diff --no-index. And it
does not contain any symlink resolution, right?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Do check_repository_format() early
From: Junio C Hamano @ 2007-12-03 18:07 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Junio C Hamano, Johannes Schindelin, git
In-Reply-To: <fcaeb9bf0712030604o2efc90d0m148d3280aaa475a5@mail.gmail.com>
"Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:
> On Dec 2, 2007 1:58 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> * Similarly, run a few commands in modes that do not require git
>> repository. For example, "git apply --stat" of an existing patch
>> should be viewable no matter where you are (that is just a "better
>> diffstat" mode), so ideally it should not barf only because you
>> happen to be in a repository that is too new for you to understand.
>> I do not know offhand how your patch would handle this situation.
>>
>> Note that making sure the latter works is tricky to do right, for a few
>> reasons.
>>
>> (1) It is not absolutely clear what the right behaviour is. It could
>> be argued that we should just barf saying we found a repository we
>> do not understand, refraining from doing any damange on it [*2*].
>>
>> (2) If we choose not to barf on such a repository, it remains to be
>> decided what "gently" should do --- if it should still treat
>> t/trash/test (which has too new a version) as the found repository,
>> or ignore it and use t/trash (which we can understand) as the found
>> repository. I think it should do the former.
>
> You might have forgotten the third choice: ignore t/trash/test and
> stop searching, instead pretend there is no repository at all (maybe
> with a big warning of unsupported repository).
>
> I agree t/trash should not be touched no matter what. I had enough
> "fun" with nested gitdir already. But if _gently() treats t/trash/test
> as a good repository, mysterious things may happen. Suppose gitdir v2
> supports some crazy refspec that current installed git cannot
> understand. Now you run git-remote on a v2 repository, it would end up
> barfing "invalid refspec" or something instead of "your repository
> version is not supported, upgrade git now". The latter error message
> is much clearer IMHO.
>
> If we are going "t/trash/test is good repo" route, we must make sure
> _gently() callers check repository version (and barf at proper places)
> before actually using it. Doing so makes repo version checking in
> _gently redundant, you need to check it from callers anyway as the
> callers will decide when to barf. Or return *nongit_ok=-1 and let the
> callers check return value so they do not need to run
> check_repository_format_version() again.
>
> Comments?
I think I phrased the above (2) not brilliantly. I meant your "third
choice" is the sane approach. Treat t/trash/test as a found place that
we do not understand, perhaps issue a warning saying that we will
operate in there but the repository version is too new for us to
understand, but still go ahead and operate in there without doing any
repository operation (so the plain git-apply without --index will act as
if it is a GNU patch called to modify files in that directory).
^ permalink raw reply
* Re: v1.5.4 plans
From: Nicolas Pitre @ 2007-12-03 18:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk5nwu51x.fsf@gitster.siamese.dyndns.org>
On Sun, 2 Dec 2007, Junio C Hamano wrote:
> Please do not take this as the final decision made by the Emperor, whose
> subjects now must follow. This is a sanity-check to see if everybody is
> on the same page.
>
> I am not the Emperor anyway ;-)
Emperor of the Rising Sun. ;-)
> Deprecation and Removal
> -----------------------
>
> * We also will give deprecation warning for the following features and
> commands in the release notes to v1.5.4, and remove them in v1.5.5:
>
> - lost-found (use fsck --lost-found);
> - post-update hook (use post-receive hook);
> - peek-remote (use ls-remote)
Two things I would like to see in the next version (1.5.5) as well, for
which we could provide early warnings now:
- repack.usedeltabaseoffset defaulting to true
- pack.indexversion defaulting to 2
Nicolas
^ permalink raw reply
* Re: [PATCH] Reorder msgfmt command-line arguments.
From: Johannes Schindelin @ 2007-12-03 18:05 UTC (permalink / raw)
To: brian m. carlson; +Cc: git
In-Reply-To: <20071203170402.GA13712@crustytoothpaste.ath.cx>
Hi,
On Mon, 3 Dec 2007, brian m. carlson wrote:
> On Mon, Dec 03, 2007 at 10:35:33AM +0000, Johannes Schindelin wrote:
> > On Mon, 3 Dec 2007, brian m. carlson wrote:
> >
> > > Any program using getopt or getopt_long will stop processing options
> > > once a non-option argument has been encountered, if POSIXLY_CORRECT
> > > is set.
> >
> > So have you tested that msgfmt indeed does not work with the present
> > command line?
>
> Yes. I run with POSIXLY_CORRECT set to 1, and it does indeed break. I
> wouldn't have fixed it if it had worked.
Ah, so it is a not-so-common breakage.
Thanks for clarifying,
Dscho
^ permalink raw reply
* Re: [PATCH] git-commit --allow-empty
From: Nicolas Pitre @ 2007-12-03 17:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Mark Drago, stelian, git
In-Reply-To: <7v63zgkw0x.fsf@gitster.siamese.dyndns.org>
On Mon, 3 Dec 2007, Junio C Hamano wrote:
> +--allow-empty::
> + Usually recording a commit that has the exact same tree as its
> + sole parent commit and the command prevents you from making such
> + a mistake. This option bypasses the safety, and is primarily
> + for use by foreign scm interface scripts.
The first sentence is rather buggy I would say.
Nicolas
^ permalink raw reply
* Re: git-svn: .git/svn disk usage
From: Ollie Wild @ 2007-12-03 17:35 UTC (permalink / raw)
To: Pascal Obry, Ollie Wild, git
In-Reply-To: <20071203064603.GA18583@old.davidb.org>
On Dec 2, 2007 10:46 PM, David Brown <git@davidb.org> wrote:
>
> Ollie, if you look in these svn branch directories, is most of the space
> taken up with files called 'index'?
I'm seeing the following breakdown:
4.3G index
77M unhandled.log
5.5G .rev_db.138bc75d-0d04-0410-961f-82ee72b054a4
What exactly are the index and .rev_db files used for?
Ollie
^ permalink raw reply
* Re: [PATCH/RFC] Use regex for :/ matching
From: Jeff King @ 2007-12-03 17:30 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0712031052410.27959@racer.site>
On Mon, Dec 03, 2007 at 10:55:15AM +0000, Johannes Schindelin wrote:
> > The sha1 syntax :/ used to be a strict prefix match.
> > Instead, let's use a regular expression, which can save on
> Heh:
> http://repo.or.cz/w/git/dscho.git?a=commitdiff;h=2546cd9732bb8d4bc1d2485ba7bbc1d5c8bac935
Hmm, the major difference seems to be that you grep the entire body,
whereas I grep just the oneline. My goal was to avoid matching the
search string in the message of a merge commit with merge summaries
turned on.
> Except that I did not support ".." (does yours?), _and_ that my patch is
> not as nice as yours.
No, I didn't. I'm not sure it is sane, since :/ can contain free-form
text (and with a regex, .. is not that unlikely). And you can always do
git-log --not :/foo :/bar
> But then, my patch also works when save_commit_buffer == 0. But I can
> refactor this into its own patch, since it really is a separate issue.
Agreed.
-Peff
^ permalink raw reply
* Re: Incorrect git-blame result if I use full path to file
From: Linus Torvalds @ 2007-12-03 17:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Anatol Pomozov, git
In-Reply-To: <7vhcj0seok.fsf@gitster.siamese.dyndns.org>
On Sun, 2 Dec 2007, Junio C Hamano wrote:
> "Anatol Pomozov" <anatol.pomozov@gmail.com> writes:
> >
> > I just start learning git and I found a bug (but sorry if the
> > functionality I am trying to blame as a bug not actually bug and it
> > was made by intention)
>
> I think it is rather a sloppy error checking than a bug. It should be
> throwing a stone back at you when you feed it a full path, or converting
> it back to work tree relative path before using.
How about this patch?
It makes "get_pathspec()" make all the paths it returns relative, if it
can. HOWEVER! I think it should actually die() if it sees an absolute path
that it cannot convert (because it really cannot do anything sane about
it), but I commented that out for now because that requires some test case
change: right now we actually have a few test cases for insane filename
arguments, and they expect the old behaviour.
Comments? This changes behaviour subtly (and if we enable the "die(..)"
logic, not-so-subtly), but I think that in any case where it changes
behaviour, the new behaviour would be an improvement, and the old one
would be nonsensical (ie you get *some* results with an absolute pathname,
just not the ones you'd expect!)
Note the die() comment in the bad case in "make_relative()".
Linus
---
setup.c | 34 +++++++++++++++++++++++++++++++++-
1 files changed, 33 insertions(+), 1 deletions(-)
diff --git a/setup.c b/setup.c
index 2c7b5cb..fadf4ee 100644
--- a/setup.c
+++ b/setup.c
@@ -111,11 +111,26 @@ void verify_non_filename(const char *prefix, const char *arg)
die("'%s': %s", arg, strerror(errno));
}
+static const char *make_relative(const char *file, const char *pwd, int pwdlen)
+{
+ if (strncmp(file, pwd, pwdlen))
+ goto bad;
+ if (file[pwdlen] != '/')
+ goto bad;
+ return file + pwdlen + 1;
+
+bad:
+ /* Should we die() here or just do a "return file"? */
+ /* die("pathname '%s' is not in the repository", file); */
+ return file;
+}
+
const char **get_pathspec(const char *prefix, const char **pathspec)
{
+ const char *pwd;
const char *entry = *pathspec;
const char **p;
- int prefixlen;
+ int prefixlen, pwdlen;
if (!prefix && !entry)
return NULL;
@@ -127,9 +142,26 @@ const char **get_pathspec(const char *prefix, const char **pathspec)
return spec;
}
+ pwd = NULL;
+ pwdlen = 0;
+ p = pathspec;
+ do {
+ if (*entry == '/') {
+ if (!pwd) {
+ char buffer[PATH_MAX + 1];
+ if (!getcwd(buffer, sizeof(buffer)))
+ break;
+ pwd = buffer;
+ pwdlen = strlen(buffer);
+ }
+ *p = make_relative(entry, pwd, pwdlen);
+ }
+ } while ((entry = *++p) != NULL);
+
/* Otherwise we have to re-write the entries.. */
p = pathspec;
prefixlen = prefix ? strlen(prefix) : 0;
+ entry = *p;
do {
*p = prefix_path(prefix, prefixlen, entry);
} while ((entry = *++p) != NULL);
^ permalink raw reply related
* Re: [PATCH] Fix quote_path when called with negative length.
From: Jeff King @ 2007-12-03 17:18 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <20071203090652.GA25154@artemis.madism.org>
On Mon, Dec 03, 2007 at 10:06:52AM +0100, Pierre Habouzit wrote:
> Speaking of which, there is this irritating bug in git status that
> let it show too long paths in the first chunk (the "tracked files"
> one).
It was annoying me, too. See the thread 'quote_path: fix collapsing of
relative paths'.
-Peff
^ permalink raw reply
* Re: [PATCH] Adding menu for Emacs git.el
From: Alexandre Julliard @ 2007-12-03 17:13 UTC (permalink / raw)
To: Remi Vanicat; +Cc: git
In-Reply-To: <877ijwfh6z.dlv@vanicat.homelinux.org>
Remi Vanicat <vanicat@debian.org> writes:
> Here is the corrected patch
> [...]
>
>> BTW do you have a copyright assignment for Emacs?
> No, should I seek one ?
It's not necessary right now, but I'm hoping that git.el will eventually
be merged into the main Emacs tree, and at that point we'll need a
copyright assignment from you.
> + ["Interctive Diff File" git-diff-file-idiff t]
The typo is still here.
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply
* Re: Fix UTF Encoding issue
From: Martin Koegler @ 2007-12-03 16:38 UTC (permalink / raw)
To: Jakub Narebski
Cc: Ismail Dönmez, Junio C Hamano, Alexandre Julliard,
Benjamin Close, git
In-Reply-To: <m3prxougmx.fsf@roke.D-201>
On Mon, Dec 03, 2007 at 04:06:48AM -0800, Jakub Narebski wrote:
> Ismail Dönmez <ismail@pardus.org.tr> writes:
> > Monday 03 December 2007 Tarihinde 12:14:43 yazm??t?:
> >> Benjamin Close <Benjamin.Close@clearchain.com> writes:
> >>> - eval { $res = decode_utf8($str, Encode::FB_CROAK); };
> >>> - if (defined $res) {
> >>> - return $res;
> >>> - } else {
> >>> - return decode($fallback_encoding, $str, Encode::FB_DEFAULT);
> >>> - }
> >>> + eval { return ($res = decode_utf8($str, Encode::FB_CROAK)); };
> >>> + return decode($fallback_encoding, $str, Encode::FB_DEFAULT);
> >>> }
This version is broken on Debian sarge and etch. Feeding a UTF-8 and a latin1
encoding of the same character sequence yields to different results.
> >>
> >> I thought the standard catch ... throw idiom in Perl was to do the above
> >> like this:
> >>
> >> my $res;
> >> eval { $res = decode_utf8($str, Encode::FB_CROAK); };
> >> if ($@) {
> >> return decode($fallback_encoding, $str, Encode::FB_DEFAULT);
> >> }
> >> return $res;
> >
> > I think this is correct, but the current code in gitweb doesn't look correct
> > since it checks for $res and not $@.
>
> First version of the patch was created by Martin Koegler. I have
> participated in creating the version which is now in gitweb, but I
> have to say that I wrote it based on decode_utf8
> documentation... which doesn't necessarily agree with facts :-(
eval { $res = decode_utf8(...); }
if ($@)
return decode(...);
return $res
or
eval { $res = decode_utf8(...); }
if (defined $res)
return $res;
else
return decode(...);
show the same (wrong) behaviour on Debian sarge. They do not always
decode non UTF-8 characters correctly, eg.
#öäü does not work
#äöüä does work
On Debian etch, both versions are working.
> I'm all for the "throw idion" version. Ack.
mfg Martin Kögler
^ permalink raw reply
* Re: [PATCH] Reorder msgfmt command-line arguments.
From: brian m. carlson @ 2007-12-03 17:04 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0712031034200.27959@racer.site>
On Mon, Dec 03, 2007 at 10:35:33AM +0000, Johannes Schindelin wrote:
>On Mon, 3 Dec 2007, brian m. carlson wrote:
>
>> Any program using getopt or getopt_long will stop processing options
>> once a non-option argument has been encountered, if POSIXLY_CORRECT is
>> set.
>
>So have you tested that msgfmt indeed does not work with the present
>command line?
Yes. I run with POSIXLY_CORRECT set to 1, and it does indeed break. I
wouldn't have fixed it if it had worked.
There are parts of the git testsuite that hang in this case, too, but I
have yet to examine them. Rest assured that there are indeed patches
coming, assuming the problems are fixable.
>Besides, you probably want to send this as a git-gui patch: based on
>git-gui.git, not git.git, and Cc'ed to Shawn Pearce.
Thanks. Will do.
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
a typesetting engine: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
^ permalink raw reply
* Re: Fix UTF Encoding issue
From: Jakub Narebski @ 2007-12-03 17:02 UTC (permalink / raw)
To: Martin Koegler
Cc: Ismail Dönmez, Junio C Hamano, Alexandre Julliard,
Benjamin Close, git, Perl Unicode Mailing List, Dan Kogai
In-Reply-To: <20071203163856.GA24269@auto.tuwien.ac.at>
On Mon, 3 Dec 2007, Martin Koegler wrote:
> On Mon, Dec 03, 2007 at 04:06:48AM -0800, Jakub Narebski wrote:
>> Ismail Dönmez <ismail@pardus.org.tr> writes:
>>> Monday 03 December 2007 Tarihinde 12:14:43 yazm??t?:
>>>> Benjamin Close <Benjamin.Close@clearchain.com> writes:
>>>>> - eval { $res = decode_utf8($str, Encode::FB_CROAK); };
>>>>> - if (defined $res) {
>>>>> - return $res;
>>>>> - } else {
>>>>> - return decode($fallback_encoding, $str, Encode::FB_DEFAULT);
>>>>> - }
>>>>> + eval { return ($res = decode_utf8($str, Encode::FB_CROAK)); };
>>>>> + return decode($fallback_encoding, $str, Encode::FB_DEFAULT);
>>>>> }
>
> This version is broken on Debian sarge and etch. Feeding a UTF-8 and a latin1
> encoding of the same character sequence yields to different results.
[...]
> eval { $res = decode_utf8(...); }
> if ($@)
> return decode(...);
> return $res
>
> or
>
> eval { $res = decode_utf8(...); }
> if (defined $res)
> return $res;
> else
> return decode(...);
>
> show the same (wrong) behaviour on Debian sarge. They do not always
> decode non UTF-8 characters correctly, eg.
> #öäü does not work
> #äöüä does work
>
> On Debian etch, both versions are working.
I don't know enough Perl to decide if it is a bug in gitweb usage
of decode_utf8, if it is a bug in your version of Encode, or if it
is bug in Encode.
Send copy of this mail to maintainers of Encode perl module.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [REGRESSION ?] git-remote "--mirror" option is not integrated in 1.5.3.7
From: Johannes Schindelin @ 2007-12-03 16:23 UTC (permalink / raw)
To: Felipe Balbi; +Cc: git
In-Reply-To: <31e679430712030532p12e1f0f5x7e10bd0a1fdf9ef9@mail.gmail.com>
Hi,
On Mon, 3 Dec 2007, Felipe Balbi wrote:
> I've using git-remote --mirror mode for while right now but I saw it's
> not integrated in v.1.5.3.7, is this on purpose? I can still get it if I
> compile recent git's head "36863af16e91aebc87696209f4f4780cf4c4059f".
AFAICT there are problems with --prune. That might be a reason that it is
not in 1.5.3.7 (haven't checked if that's even the case, though).
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Open external merge tool with original file extensions in all three files
From: Pini Reznik @ 2007-12-03 15:31 UTC (permalink / raw)
To: git; +Cc: Pini Reznik
This required to be able to use syntax highlighting in meld during conflicts resolution.
Before this change, two merged versions of file with a conflict were open with temporal extensions .LOCAL.$$ and REMOTE.$$
This way they were not recognized as a code files.
Signed-off-by: Pini Reznik <pinir@expand.com>
---
git-mergetool.sh | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/git-mergetool.sh b/git-mergetool.sh
index 5587c5e..4c15d22 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -152,10 +152,11 @@ merge_file () {
exit 1
fi
- BACKUP="$path.BACKUP.$$"
- LOCAL="$path.LOCAL.$$"
- REMOTE="$path.REMOTE.$$"
- BASE="$path.BASE.$$"
+ extension=`echo $path | awk -F \. '{print $NF}'`
+ BACKUP="$path.BACKUP.$$.${extension}"
+ LOCAL="$path.LOCAL.$$.${extension}"
+ REMOTE="$path.REMOTE.$$.${extension}"
+ BASE="$path.BASE.$$.${extension}"
mv -- "$path" "$BACKUP"
cp -- "$BACKUP" "$path"
--
1.5.3.5
^ permalink raw reply related
* Re: committing only selected diff's of a file
From: Matthieu Moy @ 2007-12-03 16:00 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Erik Colson, git
In-Reply-To: <m3tzn0uj9s.fsf@roke.D-201>
Jakub Narebski <jnareb@gmail.com> writes:
> "git gui" (the latter requires Tcl/Tk).
... Right click on a patch hunk, "stage for commit".
--
Matthieu
^ permalink raw reply
* Re: [PATCH] Do check_repository_format() early
From: Nguyen Thai Ngoc Duy @ 2007-12-03 14:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7v4pf25jiq.fsf@gitster.siamese.dyndns.org>
On Dec 2, 2007 1:58 AM, Junio C Hamano <gitster@pobox.com> wrote:
> * Similarly, run a few commands in modes that do not require git
> repository. For example, "git apply --stat" of an existing patch
> should be viewable no matter where you are (that is just a "better
> diffstat" mode), so ideally it should not barf only because you
> happen to be in a repository that is too new for you to understand.
> I do not know offhand how your patch would handle this situation.
>
> Note that making sure the latter works is tricky to do right, for a few
> reasons.
>
> (1) It is not absolutely clear what the right behaviour is. It could
> be argued that we should just barf saying we found a repository we
> do not understand, refraining from doing any damange on it [*2*].
>
> (2) If we choose not to barf on such a repository, it remains to be
> decided what "gently" should do --- if it should still treat
> t/trash/test (which has too new a version) as the found repository,
> or ignore it and use t/trash (which we can understand) as the found
> repository. I think it should do the former.
You might have forgotten the third choice: ignore t/trash/test and
stop searching, instead pretend there is no repository at all (maybe
with a big warning of unsupported repository).
I agree t/trash should not be touched no matter what. I had enough
"fun" with nested gitdir already. But if _gently() treats t/trash/test
as a good repository, mysterious things may happen. Suppose gitdir v2
supports some crazy refspec that current installed git cannot
understand. Now you run git-remote on a v2 repository, it would end up
barfing "invalid refspec" or something instead of "your repository
version is not supported, upgrade git now". The latter error message
is much clearer IMHO.
If we are going "t/trash/test is good repo" route, we must make sure
_gently() callers check repository version (and barf at proper places)
before actually using it. Doing so makes repo version checking in
_gently redundant, you need to check it from callers anyway as the
callers will decide when to barf. Or return *nongit_ok=-1 and let the
callers check return value so they do not need to run
check_repository_format_version() again.
Comments?
--
Duy
^ permalink raw reply
* [REGRESSION ?] git-remote "--mirror" option is not integrated in 1.5.3.7
From: Felipe Balbi @ 2007-12-03 13:32 UTC (permalink / raw)
To: git
Hi all,
I've using git-remote --mirror mode for while right now but I saw it's
not integrated in v.1.5.3.7, is this on purpose?
I can still get it if I compile recent git's head
"36863af16e91aebc87696209f4f4780cf4c4059f".
--
Best Regards,
Felipe Balbi
felipebalbi@users.sourceforge.net
^ permalink raw reply
* Re: [PATCH v2] Teach 'git pull' about --rebase
From: Karl Hasselström @ 2007-12-03 13:10 UTC (permalink / raw)
To: Björn Steinbrink
Cc: Junio C Hamano, Lars Hjemli, Johannes Schindelin, Steven Grimm,
Linus Torvalds, git
In-Reply-To: <20071201203759.GA11710@atjola.homenet>
On 2007-12-01 21:37:59 +0100, Björn Steinbrink wrote:
> So how about adding --fetch/--no-fetch (maybe with a configurable
> default?) to git-merge/git-rebase and deprecate git-pull over time?
FWIW, I like this idea. rebase/merge is the complicated part of the
operation, so the UI should focus on that. Updating or not updating
the remote-tracking branch that is merged from/rebased on is a simple
binary choice, so a flag is perfect.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: What's in git-gui.git
From: Johannes Schindelin @ 2007-12-03 13:14 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Shawn O. Pearce, git, Junio C Hamano
In-Reply-To: <20071203094219.GW31750@genesis.frugalware.org>
Hi,
On Mon, 3 Dec 2007, Miklos Vajna wrote:
> On Sun, Dec 02, 2007 at 11:10:10PM -0500, "Shawn O. Pearce" <spearce@spearce.org> wrote:
> > The following changes since gitgui-0.9.0 are now in my git-gui
> > master branch. I'm considering tagging a 0.9.1 release next week.
> >
> > gitweb: http://repo.or.cz/w/git-gui.git
> > clone: git://repo.or.cz/git-gui.git
> > http://repo.or.cz/r/git-gui.git
>
> the README says that one should push translation updates to the mob
> branch of git-gui-i18n.git, but if i'm not wrong de.po is newer in
> gui-gui.git than the one in git-gui-i18n.git. have i missed something or
> the README is just a bit outdated?
The git-gui-i18n maintainer got distracted.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] quote_path: fix collapsing of relative paths
From: Johannes Schindelin @ 2007-12-03 12:32 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20071203053001.GA12696@coredump.intra.peff.net>
Hi,
On Mon, 3 Dec 2007, Jeff King wrote:
> This behavior in git-status had been bugging me, and when I went to fix
> it, I was surprised to find code already there to do it. :) Dscho,
> please confirm that the test is in fact in error, and that I've read the
> intent of your code correctly.
Yes, you did.
Ciao,
Dscho
^ permalink raw reply
* Re: Fix UTF Encoding issue
From: Jakub Narebski @ 2007-12-03 12:06 UTC (permalink / raw)
To: Ismail Dönmez
Cc: Junio C Hamano, Martin Koegler, Alexandre Julliard,
Benjamin Close, git
In-Reply-To: <200712031332.36187.ismail@pardus.org.tr>
Ismail Dönmez <ismail@pardus.org.tr> writes:
> Monday 03 December 2007 Tarihinde 12:14:43 yazmıştı:
>> Benjamin Close <Benjamin.Close@clearchain.com> writes:
>>> - eval { $res = decode_utf8($str, Encode::FB_CROAK); };
>>> - if (defined $res) {
>>> - return $res;
>>> - } else {
>>> - return decode($fallback_encoding, $str, Encode::FB_DEFAULT);
>>> - }
>>> + eval { return ($res = decode_utf8($str, Encode::FB_CROAK)); };
>>> + return decode($fallback_encoding, $str, Encode::FB_DEFAULT);
>>> }
>>
>> I thought the standard catch ... throw idiom in Perl was to do the above
>> like this:
>>
>> my $res;
>> eval { $res = decode_utf8($str, Encode::FB_CROAK); };
>> if ($@) {
>> return decode($fallback_encoding, $str, Encode::FB_DEFAULT);
>> }
>> return $res;
>
> I think this is correct, but the current code in gitweb doesn't look correct
> since it checks for $res and not $@.
First version of the patch was created by Martin Koegler. I have
participated in creating the version which is now in gitweb, but I
have to say that I wrote it based on decode_utf8
documentation... which doesn't necessarily agree with facts :-(
I'm all for the "throw idion" version. Ack.
--
Jakub Narebski
^ 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