* Re: How to create & switch to a branch after changes have already been made?
From: Patrick Doyle @ 2007-07-03 14:04 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0707031210020.4071@racer.site>
The real problem was that I did a
$ git-mv somefile somefile.new
and then created a new version of "somefile". When I temporarily
renamed it, all of the given suggestions worked. Thanks.
--wpd
^ permalink raw reply
* Re: [PATCH] stash: end commit log with a newline
From: Uwe Kleine-König @ 2007-07-03 14:01 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0707031228460.4071@racer.site>
Hallo Johannes,
Johannes Schindelin wrote:
> On Tue, 3 Jul 2007, Uwe Kleine-K?nig wrote:
>
> > - w_commit=$(printf 'WIP on %s' "$msg" |
> > + w_commit=$(printf 'WIP on %s\n' "$msg" |
>
> Why not
>
> w_commit=$(echo "WIP on $msg" |
I just continued to use printf to make a minimal change. I don't have
anything against echo.
Best regards
Uwe
--
Uwe Kleine-König
http://www.google.com/search?q=5%2B7
^ permalink raw reply
* Re: git-fetch will leave a ref pointing to a tag
From: Jeff King @ 2007-07-03 13:59 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: linux, git
In-Reply-To: <Pine.LNX.4.64.0707031257590.4071@racer.site>
On Tue, Jul 03, 2007 at 01:01:49PM +0100, Johannes Schindelin wrote:
> If it is only the test, you can do that by
>
> test $(git merge-base foo bar) = $(git rev-parse foo)
I had thought that calculating the merge base was actually slightly less
efficient in this case, since it will actually find all of the merge
bases (but I could very well be wrong). But really, either should
produce the result effectively instantaneously.
> (which tests if foo is a stricth ancestor of bar). Although in your
> (linux@horizon.com's) place I would really look at "git log foo.." myself,
> as peff almost suggested.
Yes. In fact, I find an even more useful operation in that case to be
"gitk foo..." to see "where I'm at" with respect to my changes and
upstream changes.
-Peff
^ permalink raw reply
* Re: git-rm isn't the inverse action of git-add
From: Matthieu Moy @ 2007-07-03 13:40 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Yann Dirson, Christian Jaeger, git
In-Reply-To: <Pine.LNX.4.64.0707031308170.4071@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Tue, 3 Jul 2007, Matthieu Moy wrote:
>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>
>> > What's so wrong with our man pages? You know, there have been man
>> > hours invested in them, and they are exclusively meant for consumption
>> > by people who do not know about the usage of the commands...
>>
>> What's wrong is just that I shouldn't have to read a man page to avoid
>> data-loss.
>
> Okay, Mr Moy.
Glad to be called by my name. Is it a tradition here, or a way to make
fun of me?
> How did you learn that "rm" leads to data-loss? Because it does.
It obviously does, and I can't imagine any other behavior than
deleting the file for a command like "rm".
> Hmm. How did you expect then, that git-rm does _not_ lead to data
> loss?
Because there are tons of possible behaviors for "$VCS rm", and I'd
expect it to be safe even if VCS=git, since it is with all the other
VCS I know.
What's wrong with the behavior of "hg rm"?
What's wrong with the behavior of "svn rm"?
What's wrong with the behavior of "bzr rm"?
(no, I won't do it with CVS ;-) )
None of these commands have the problem that git-rm has.
--
Matthieu
^ permalink raw reply
* Re: being nice to patch(1)
From: Johannes Schindelin @ 2007-07-03 13:39 UTC (permalink / raw)
To: David Kastrup; +Cc: git, quilt-dev
In-Reply-To: <86y7hxr591.fsf@lola.quinscape.zz>
Hi David,
[please Cc me, since I will be more likely to miss replies if you do not]
On Tue, 3 Jul 2007, David Kastrup wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > But maybe they would be willing to install git to get that wonderful
> > git-apply program, and that wonderful rename-and-mode-aware git-diff,
> > and the git-merge-file program, all of which can operate outside of a
> > git repository. (Take that, hg!)
>
> As long as git-diff lists all added files in a second non-git dirtree
> as "/dev/null" when doing
> git-diff --name-status -B -M -C dir1 dir2
> its usefulness is limited.
>
> git-diff --name-status -B -M -C dir1 dir2
> D dir1/auctex-11.84/CHANGES
> D dir1/auctex-11.84/COPYING
> D dir1/auctex-11.84/ChangeLog
>
> [...]
Yes, directories are a problem. There our DWIMery does not really help.
But there is a solution: say
git diff --name-status --no-index -B -M -C dir1 dir2
Hth,
Dscho
^ permalink raw reply
* Re: [Quilt-dev] Re: being nice to patch(1)
From: Andreas Gruenbacher @ 2007-07-03 13:34 UTC (permalink / raw)
To: quilt-dev; +Cc: Linus Torvalds, Andrew Morton, git
In-Reply-To: <alpine.LFD.0.98.0707021713200.9434@woody.linux-foundation.org>
On Tuesday 03 July 2007 02:28, Linus Torvalds wrote:
> So I would suggest that in quilt and other systems, you either:
>
> - strip all headers manually
>
> - forget about "patch", and use "git-apply" instead that does things
> right and doesn't screw up like this (and can do rename diffs etc too).
>
> I guess the second choice generally isn't an option, but dammit,
> "git-apply" really is the better program here.
I'm in bit of a conflict with choice one: when applying patches in an
automated build process or similar, the likely way to do so is a simple loop
over the series file. So the less magic when applying patches with quilt, the
better.
Turning off the insane heuristic with patch -u will do well enough I hope.
Quilt does not use that option by default because it also supports context
diffs (some people / projects prefer them), but that can easily be customized
in .quiltrc:
QUILT_PATCH_OPTS=-u
Andreas
^ permalink raw reply
* Re: being nice to patch(1)
From: David Kastrup @ 2007-07-03 13:22 UTC (permalink / raw)
To: git; +Cc: quilt-dev
In-Reply-To: <Pine.LNX.4.64.0707031303130.4071@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> But maybe they would be willing to install git to get that wonderful
> git-apply program, and that wonderful rename-and-mode-aware
> git-diff, and the git-merge-file program, all of which can operate
> outside of a git repository. (Take that, hg!)
As long as git-diff lists all added files in a second non-git dirtree
as "/dev/null" when doing
git-diff --name-status -B -M -C dir1 dir2
its usefulness is limited.
git-diff --name-status -B -M -C dir1 dir2
D dir1/auctex-11.84/CHANGES
D dir1/auctex-11.84/COPYING
D dir1/auctex-11.84/ChangeLog
[...]
D dir1/auctex-11.84/preview/preview-latex.spec
D dir1/auctex-11.84/preview/prv-emacs.el
D dir1/auctex-11.84/preview/prv-install.el
D dir1/auctex-11.84/tex-site.el.in
D dir1/auctex-11.84/tex-wizard.el
A /dev/null
A /dev/null
R100 dir1/auctex-11.84/images/amstex.xpm dir2/etc/auctex/images/amstex.xpm
R100 dir1/auctex-11.84/images/bibtex.xpm dir2/etc/auctex/images/bibtex.xpm
R100 dir1/auctex-11.84/images/dropdown.xpm dir2/etc/auctex/images/dropdown.xpm
[...]
R100 dir1/auctex-11.84/images/viewdvi.xpm dir2/etc/auctex/images/viewdvi.xpm
R100 dir1/auctex-11.84/images/viewpdf.xpm dir2/etc/auctex/images/viewpdf.xpm
R100 dir1/auctex-11.84/images/viewps.xpm dir2/etc/auctex/images/viewps.xpm
A /dev/null
A /dev/null
A /dev/null
A /dev/null
A /dev/null
A /dev/null
and so on.
git --version
git version 1.5.2.2.565.gde09
--
David Kastrup
^ permalink raw reply
* [Bug?] compiler warning with gcc >= 4.2
From: Frank Lichtenheld @ 2007-07-03 12:58 UTC (permalink / raw)
To: Git Mailing List
Hi,
while testing for an (probably) unrelated miscompilation bug,
I got the following warning while compiling git:
gcc-4.2 -o sha1_file.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>'
-DETC_GITCONFIG='"/home/djpig/etc/gitconfig"' -DNO_STRLCPY sha1_file.c
sha1_file.c: In function ‘check_packed_git_idx’:
sha1_file.c:523: warning: assuming signed overflow does not occur when assuming that (X + c) < X is always false
sha1_file.c:523: warning: assuming signed overflow does not occur when assuming that (X + c) < X is always false
This comes from the new -Wstrict-overflow which warns about the fact
that with -fstrict-overflow, which is activated by default with -O2,
the if clause referenced in the warning will be optimised away.
So I would be interested to know
a) if the compiler optimising this check away (which seems to be a check
about whether signed overflow can occour) can lead to unwanted results
b) if not a), if it would make sense trying to suppress that warning, so
that other people don't end up wondering the same as me
The used compiler was:
$ gcc-4.2 -v
Using built-in specs.
Target: hppa-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2
--enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr
--disable-libssp --disable-werror --enable-checking=release
--build=hppa-linux-gnu --host=hppa-linux-gnu
--target=hppa-linux-gnuThread model: posix
gcc version 4.2.1 20070627 (prerelease) (Debian 4.2-20070627-1)
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* Re: Can git-svn treat specify paths as branches ?
From: Jeffrey C. Ollie @ 2007-07-03 12:53 UTC (permalink / raw)
To: git
In-Reply-To: <4b3406f0707030212h1e029023sf74c5c7b0e95654b@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 543 bytes --]
On Tue, 2007-07-03 at 17:12 +0800, Dongsheng Song wrote:
> For google code projects, the repositories organized is:
>
> branches tags trunk wiki
>
> Can I treat wiki as a branch? i.e.
>
> [svn-remote "svn"]
> url = http://serf.googlecode.com/svn
> fetch = trunk:refs/remotes/trunk
> branches = branches/*,wiki:refs/remotes/*
> tags = tags/*:refs/remotes/tags/*
What's the structure underneath the wiki directory? If it's just
content, I'd use:
fetch = wiki:refs/remotes/wiki
Jeff
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] Remove obsolete commit-walkers
From: Bill Lear @ 2007-07-03 12:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Daniel Barkalow, git
In-Reply-To: <7vwsxiroqa.fsf@assigned-by-dhcp.cox.net>
On Monday, July 2, 2007 at 23:22:05 (-0700) Junio C Hamano writes:
>I'll apply this after 1.5.3. In the meantime, I'll do this for 1.5.3.
>
>diff --git a/Documentation/git-local-fetch.txt b/Documentation/git-local-fetch.txt
>index 19b5f88..141b767 100644
>--- a/Documentation/git-local-fetch.txt
>+++ b/Documentation/git-local-fetch.txt
>@@ -14,6 +14,8 @@ SYNOPSIS
>
> DESCRIPTION
> -----------
>+THIS COMMAND IS DEPRECATED.
>...
If a deprecated command has a replacement, the deprecation notice
should point the user to that.
Bill
^ permalink raw reply
* Re: being nice to patch(1)
From: Johannes Schindelin @ 2007-07-03 12:35 UTC (permalink / raw)
To: Paolo Ciarrocchi
Cc: Linus Torvalds, Junio C Hamano, Andrew Morton, git, quilt-dev
In-Reply-To: <4d8e3fd30707030521k6cb3129dy9193344e9e1eccf7@mail.gmail.com>
Hi,
On Tue, 3 Jul 2007, Paolo Ciarrocchi wrote:
> On 7/3/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > Hi,
> > On Mon, 2 Jul 2007, Linus Torvalds wrote:
> > > On Mon, 2 Jul 2007, Junio C Hamano wrote:
> > > > Linus Torvalds <torvalds@linux-foundation.org> writes:
> > > >
> > > > > So I would suggest that in quilt and other systems, you either:
> > > > >
> > > > > - strip all headers manually
> > > > >
> > > > > - forget about "patch", and use "git-apply" instead that does things
> > > > > right and doesn't screw up like this (and can do rename diffs etc
> > too).
> > > > >
> > > > > I guess the second choice generally isn't an option, but dammit,
> > > > > "git-apply" really is the better program here.
> > > >
> > > > Why not? git-apply works outside of a git repo ;-)
> > >
> > > I was more thinking that people are not necessarily willing to install
> > git
> > > just to get the "git-apply" program..
> >
> > But maybe they would be willing to install git to get that wonderful
> > git-apply program, and that wonderful rename-and-mode-aware git-diff, and
> > the git-merge-file program, all of which can operate outside of a git
> > repository. (Take that, hg!)
>
> How about shipping just these commands as a separate package?
> Is that a cray idea?
Heh, all three programs are "builtins", which means that you get almost
the whole package of git anyway ;-)
Ciao,
Dscho
^ permalink raw reply
* Re: being nice to patch(1)
From: Paolo Ciarrocchi @ 2007-07-03 12:21 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Linus Torvalds, Junio C Hamano, Andrew Morton, git, quilt-dev
In-Reply-To: <Pine.LNX.4.64.0707031303130.4071@racer.site>
On 7/3/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
> On Mon, 2 Jul 2007, Linus Torvalds wrote:
> > On Mon, 2 Jul 2007, Junio C Hamano wrote:
> > > Linus Torvalds <torvalds@linux-foundation.org> writes:
> > >
> > > > So I would suggest that in quilt and other systems, you either:
> > > >
> > > > - strip all headers manually
> > > >
> > > > - forget about "patch", and use "git-apply" instead that does things
> > > > right and doesn't screw up like this (and can do rename diffs etc too).
> > > >
> > > > I guess the second choice generally isn't an option, but dammit,
> > > > "git-apply" really is the better program here.
> > >
> > > Why not? git-apply works outside of a git repo ;-)
> >
> > I was more thinking that people are not necessarily willing to install git
> > just to get the "git-apply" program..
>
> But maybe they would be willing to install git to get that wonderful
> git-apply program, and that wonderful rename-and-mode-aware git-diff, and
> the git-merge-file program, all of which can operate outside of a git
> repository. (Take that, hg!)
How about shipping just these commands as a separate package?
Is that a cray idea?
ciao,
--
Paolo
"Tutto cio' che merita di essere fatto,merita di essere fatto bene"
Philip Stanhope IV conte di Chesterfield
^ permalink raw reply
* Pingback/Trackback for Git?
From: Thomas Perl @ 2007-07-03 12:12 UTC (permalink / raw)
To: git
Hello, Git users and developers!
I've been thinking about having some kind of pingback/trackback
support for Git repositories the same way pingback/trackback exist for
blogs. Apart from having a list of repository mirrors, it also allows
a developer to see a list of repositories from the same codebase.
I've outlined some ideas here, feel free to suggest implementations or
point out problems:
http://tperl.blogspot.com/2007/07/pingbacktrackback-for-git.html
Thanks,
Thomas
^ permalink raw reply
* Re: [PATCH] Make '!' aliases more useful
From: Theodore Tso @ 2007-07-03 12:10 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0707030220460.4071@racer.site>
On Tue, Jul 03, 2007 at 02:37:43AM +0100, Johannes Schindelin wrote:
> Windows support for those people unwilling to use cygwin amounts to
> anything, but a command line interface. Since aliases are _bound_ to
> the command line, I do not really get your point here.
You're right of course. <small>Never mind...</small>
- Ted
^ permalink raw reply
* Re: git-rm isn't the inverse action of git-add
From: Johannes Schindelin @ 2007-07-03 12:09 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Yann Dirson, Christian Jaeger, git
In-Reply-To: <vpqoditkc23.fsf@bauges.imag.fr>
Hi,
On Tue, 3 Jul 2007, Matthieu Moy wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > What's so wrong with our man pages? You know, there have been man
> > hours invested in them, and they are exclusively meant for consumption
> > by people who do not know about the usage of the commands...
>
> What's wrong is just that I shouldn't have to read a man page to avoid
> data-loss.
Okay, Mr Moy. How did you learn that "rm" leads to data-loss? Because it
does. Hmm. How did you expect then, that git-rm does _not_ lead to data
loss? If in doubt, you _have_ to read the manual. Especially if the tool
is powerful.
Ciao,
Dscho
^ permalink raw reply
* Re: being nice to patch(1)
From: Johannes Schindelin @ 2007-07-03 12:04 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Andrew Morton, git, quilt-dev
In-Reply-To: <alpine.LFD.0.98.0707022114000.9434@woody.linux-foundation.org>
Hi,
On Mon, 2 Jul 2007, Linus Torvalds wrote:
> On Mon, 2 Jul 2007, Junio C Hamano wrote:
> > Linus Torvalds <torvalds@linux-foundation.org> writes:
> >
> > > So I would suggest that in quilt and other systems, you either:
> > >
> > > - strip all headers manually
> > >
> > > - forget about "patch", and use "git-apply" instead that does things
> > > right and doesn't screw up like this (and can do rename diffs etc too).
> > >
> > > I guess the second choice generally isn't an option, but dammit,
> > > "git-apply" really is the better program here.
> >
> > Why not? git-apply works outside of a git repo ;-)
>
> I was more thinking that people are not necessarily willing to install git
> just to get the "git-apply" program..
But maybe they would be willing to install git to get that wonderful
git-apply program, and that wonderful rename-and-mode-aware git-diff, and
the git-merge-file program, all of which can operate outside of a git
repository. (Take that, hg!)
Ciao,
Dscho
^ permalink raw reply
* Re: git-fetch will leave a ref pointing to a tag
From: Johannes Schindelin @ 2007-07-03 12:01 UTC (permalink / raw)
To: Jeff King; +Cc: linux, git
In-Reply-To: <20070703041859.GB4007@coredump.intra.peff.net>
Hi,
On Tue, 3 Jul 2007, Jeff King wrote:
> On Mon, Jul 02, 2007 at 11:23:15PM -0400, linux@horizon.com wrote:
>
> > And until git-merge-ff is available, what's the recommended way to
> > "advance master to tag <foo>, but only if that wouldn't lose anything?"
>
> You can ask "do I have anything that foo doesn't?":
>
> test "`git-rev-list foo.. | wc -l`" -gt 0
If it is only the test, you can do that by
test $(git merge-base foo bar) = $(git rev-parse foo)
(which tests if foo is a stricth ancestor of bar). Although in your
(linux@horizon.com's) place I would really look at "git log foo.." myself,
as peff almost suggested.
For if you (linux@horizon.com) _have_ changes, you want to know which
changes they are, right?
Of course, it seems to me that what you (linux@horizon.com; do you really
have no proper name?) _really_ wanted to do is "git rebase v2.6.22-rc7".
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Don't smash stack when $GIT_ALTERNATE_OBJECT_DIRECTORIES is too long
From: Jim Meyering @ 2007-07-03 10:40 UTC (permalink / raw)
To: git
There is no restriction on the length of the name returned by
get_object_directory, other than the fact that it must be a stat'able
git object directory. That means its name may have length up to
PATH_MAX-1 (i.e., often 4095) not counting the trailing NUL.
Combine that with the assumption that the concatenation of that name and
suffixes like "/info/alternates" and "/pack/---long-name---.idx" will fit
in a buffer of length PATH_MAX, and you see the problem. Here's a fix:
sha1_file.c (prepare_packed_git_one): Lengthen "path" buffer
so we are guaranteed to be able to append "/pack/" without checking.
Skip any directory entry that is too long to be appended.
(read_info_alternates): Protect against a similar buffer overrun.
Before this change, using the following admittedly contrived environment
setting would cause many git commands to clobber their stack and segfault
on a system with PATH_MAX == 4096:
t=$(perl -e '$s=".git/objects";$n=(4096-6-length($s))/2;print "./"x$n . $s')
export GIT_ALTERNATE_OBJECT_DIRECTORIES=$t
touch g
./git-update-index --add g
If you run the above commands, you'll soon notice that many
git commands now segfault, so you'll want to do this:
unset GIT_ALTERNATE_OBJECT_DIRECTORIES
Signed-off-by: Jim Meyering <jim@meyering.net>
---
sha1_file.c | 16 +++++++++++++---
1 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index f2b1ae0..1efd9ae 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -352,10 +352,14 @@ static void read_info_alternates(const char * relative_base, int depth)
char *map;
size_t mapsz;
struct stat st;
- char path[PATH_MAX];
+ const char alt_file_name[] = "info/alternates";
+ /* Given that relative_base is no longer than PATH_MAX,
+ ensure that "path" has enough space to append "/", the
+ file name, "info/alternates", and a trailing NUL. */
+ char path[PATH_MAX + 1 + sizeof alt_file_name];
int fd;
- sprintf(path, "%s/info/alternates", relative_base);
+ sprintf(path, "%s/%s", relative_base, alt_file_name);
fd = open(path, O_RDONLY);
if (fd < 0)
return;
@@ -836,7 +840,10 @@ void install_packed_git(struct packed_git *pack)
static void prepare_packed_git_one(char *objdir, int local)
{
- char path[PATH_MAX];
+ /* Ensure that this buffer is large enough so that we can
+ append "/pack/" without clobbering the stack even if
+ strlen(objdir) were PATH_MAX. */
+ char path[PATH_MAX + 1 + 4 + 1 + 1];
int len;
DIR *dir;
struct dirent *de;
@@ -858,6 +865,9 @@ static void prepare_packed_git_one(char *objdir, int local)
if (!has_extension(de->d_name, ".idx"))
continue;
+ if (len + namelen + 1 > sizeof(path))
+ continue;
+
/* Don't reopen a pack we already have. */
strcpy(path + len, de->d_name);
for (p = packed_git; p; p = p->next) {
--
1.5.2.2.646.g71e55-dirty
^ permalink raw reply related
* Re: Starting 1.5.3 stabilization cycle
From: Frank Lichtenheld @ 2007-07-03 11:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8x9yrllv.fsf@assigned-by-dhcp.cox.net>
On Tue, Jul 03, 2007 at 12:29:32AM -0700, Junio C Hamano wrote:
> GIT v1.5.3 Release Notes (draft as of -rc0)
> ========================
>
> Updates since v1.5.2
> --------------------
>
> * The commit walkers other than http are officially deprecated
> (but still supported).
>
> * The submodule support has Porcelain layer now.
>
> * An initial interation of Porcelain level superproject support
> started to take shape.
Should that be "iteration"?
> * Thee are a handful pack-objects changes to help you cope better with
> repositories with pathologically large blobs in them.
"There"?
> * Updated behavior of existing commands.
>
> - "git svn dcommit" retains local merge information.
>
> - "git config" to set values also honor type flags like --bool
> and --int.
"honors"
> - "git cvsimort" creates lightweight tag; there is not any
> interesting information we can record in an annotated tag,
> and the handcrafted ones the old code created was not
> properly formed anyway.
"lightweight tags"
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* Re: [PATCH] stash: end commit log with a newline
From: Johannes Schindelin @ 2007-07-03 11:29 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: Git Mailing List
In-Reply-To: <20070703085906.GA4963@lala>
Hi,
On Tue, 3 Jul 2007, Uwe Kleine-K?nig wrote:
> - w_commit=$(printf 'WIP on %s' "$msg" |
> + w_commit=$(printf 'WIP on %s\n' "$msg" |
Why not
w_commit=$(echo "WIP on $msg" |
Hmm? It is shorter and more to the point. IMHO it is also more common.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Make '!' aliases more useful
From: Johannes Schindelin @ 2007-07-03 11:27 UTC (permalink / raw)
To: Alex Riesen; +Cc: Theodore Tso, git, gitster
In-Reply-To: <81b0412b0707030007o328f0b35hfa758e1f3b2ef289@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2082 bytes --]
Hi,
On Tue, 3 Jul 2007, Alex Riesen wrote:
> On 7/2/07, Theodore Tso <tytso@mit.edu> wrote:
> > On Mon, Jul 02, 2007 at 04:55:24PM +0100, Johannes Schindelin wrote:
> > > > But what if you don't want the argument passed at the end of the
> > > > alias, but somewhere else? I suspect the better answer would be to
> > > > support $* and $1, $2, $3, et. al interpolation, no? It was on my
> > > > list of things to do when I had a spare moment, but I never got around
> > > > to it.
> > >
> > > There is a point where you do not want to complicate git, but rather
> > write
> > > a script. This is such a point IMHO.
> >
> > Such a point exists, I agree, but I would draw after $* and $1/$2/$3
> > interpolation. There is a lot more value that gets added with
> > positional arguments support, and it makes git aliases more usable on
> > platforms such as Windows where scripting capability is much more
> > limited.
>
> I don't think it is _possible_ to make it work on Windows properly: you have
> to quote the arguments with whitespaces as there is nothing like argv there
> (windows programs don't use command line, so it does not exist).
Since the "!" aliases use system() (i.e. no argv, but a plain string as
parameter), my patch already does that. It quotes the arguments properly.
> As the quoting is implemented in the programs the rules are all different
> and mostly suboptimal.
You mean the programs that could be called via "!" aliases? Yes, that is
right. And there is also the problem that you have to convert path names
if you are working on Windows, because of this c:\&@!§$ braindamage.
However, in this case Junio's idea to use the shell to do the hard work is
again an alternative:
[alias]
alex = !sh -c 'd:\program.exe $(cygpath -w "$1")'
FWIW I do not think that executing the shell from time to time is a big
problem. It's only that I would like to get rid of the dependency on perl
and bash for the plain Windows user, who will not dare to leave the gui
into the command line jungle where there be bisons, yaccs and kills.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Teach git-stash to "apply --index"
From: Johannes Schindelin @ 2007-07-03 11:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vodiut8c3.fsf@assigned-by-dhcp.cox.net>
Hi,
On Mon, 2 Jul 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > I am not quite sure if this should not be the default, with
> > --skip-index to turn it off if the trivial index merge fails,
> > and the user might be interested only in the working directory
> > changes anyway.
> >
> > Comments?
>
> There is a bit of impedance mismatch between a rename-aware
> three-way merge (aka merge-recursive) used to update the working
> tree and a patch that updates the index. The "rename-aware"
> thing can be fixed by doing the diff with -M, though.
Ah yes, I did not think about renames. But like you said, adding -M to the
diff should help that.
> It might be easier to explain (1) not have --index option, but attempt
> to do this always, and (2) even if the index cannot be updated, keep
> going, without worrying about losing the difference between I and W,
> probably with a message to the end user.
Okay, in this case I propose to make this the default, with an option
"--skip-index" to only try re-apply the changes to the working directory.
> Suppose you are the user who gets "perhaps you would want to run without
> --index?" hint. What can you do? Run without --index, or forget about
> unstashing. But the latter does not sound like an option. So it feels
> to me that --index is an unnecessary option.
It is very much like the choice you have with "git checkout" vs "git
checkout -f". Either you change your index accordingly, or you say "I
don't care about the index. What changes I had there, I will reconstruct
myself."
> The potential confusion problem I mentioned in two of my earlier
> messages due to the program doing one thing sometimes and another thing
> some other times still applies, though.
Yes, that's why I would suggest not going ahead when the index could not
be easily merged. Rather give the user enough information to decide.
Of course, this means that in complicated cases, the user mustn't run and
hide when she hears "index!", but I guess that complicated cases always
need you to know your tools better than easy problems.
Ciao,
Dscho
^ permalink raw reply
* Re: How to create & switch to a branch after changes have already been made?
From: Johannes Schindelin @ 2007-07-03 11:10 UTC (permalink / raw)
To: Patrick Doyle; +Cc: git
In-Reply-To: <e2a1d0aa0707021949k181f9042j26ebd124f61ca1ae@mail.gmail.com>
Hi,
On Mon, 2 Jul 2007, Patrick Doyle wrote:
> Hmmm... One thing I might tell the hypothetical person is to temporarily
> delete or rename the new version of "somefile", so that the merge could
> complete with problems, and then recreate or rename it back. That would
> probably allow the hypothetical person to continue his/her work.
You could also say "git checkout -f newbranch".
Ciao,
Dscho
^ permalink raw reply
* Re: git-rm isn't the inverse action of git-add
From: Matthieu Moy @ 2007-07-03 10:37 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Yann Dirson, Christian Jaeger, git
In-Reply-To: <Pine.LNX.4.64.0707022205210.4071@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> What's so wrong with our man pages? You know, there have been man hours
> invested in them, and they are exclusively meant for consumption by people
> who do not know about the usage of the commands...
What's wrong is just that I shouldn't have to read a man page to avoid
data-loss. I should have to read them to do non-trivial things, for
sure.
Useability is not just about documenting surprising behaviors, it's
really about avoiding them.
--
Matthieu
^ permalink raw reply
* Re: git-svn dcommit fails if the URL has spaces in it
From: Rogan Dawes @ 2007-07-03 9:49 UTC (permalink / raw)
Cc: Git Mailing List, Eric Wong
In-Reply-To: <4680F75A.9010704@dawes.za.net>
Rogan Dawes wrote:
> Hi folks,
>
> I used git-svn to clone the webgoat repository at GoogleCode. As
> mentioned at the time, for some bizarre reason, I ended up getting a
> directory with a space character in it.
>
> See http://article.gmane.org/gmane.comp.version-control.git/49179
>
> In order to get a checkout that looks the same as the SVN checkout, I
> had to use a command line like:
>
> git-svn clone -T "trunk/ webgoat" https://webgoat.googlecode.com/svn/
>
> Unfortunately, this results in git-svn-id metadata entries in the
> commits that look like:
>
> git-svn-id: https://webgoat.googlecode.com/svn/trunk/ webgoat@2
> 4033779f-a91e-0410-96ef-6bf7bf53c507
>
> (Should be all on one line). As you can see, the space has made it
> through into the git-svn-id. Which then breaks this pattern match in
> git-svn:extract_metadata:
>
> my ($url, $rev, $uuid) = ($id =~ /^git-svn-id:\s(\S+?)\@(\d+)
> \s([a-f\d\-]+)$/x);
>
> Unfortunately, hacking it to ignore the space doesn't help either, as I
> then get:
>
> [rdawes@lucas webgoat]$ git-svn --username=rogan.dawes dcommit
> ID = git-svn-id: https://webgoat.googlecode.com/svn/trunk/ webgoat@125
> 4033779f-a91e-0410-96ef-6bf7bf53c507
> ID = git-svn-id: https://webgoat.googlecode.com/svn/trunk/ webgoat@125
> 4033779f-a91e-0410-96ef-6bf7bf53c507
> RA layer request failed: PROPFIND request failed on '/svn/trunk/
> webgoat': PROPFIND of '/svn/trunk/ webgoat': 400 Bad Request
> (https://webgoat.googlecode.com) at /home/rdawes/bin/git-svn line 406
>
> Which is entirely unsurprising, since I suspect that the URL was not
> being quoted/escaped correctly, and we were sending something like:
>
> PROPFIND /svn/trunk/ webgoat/ HTTP/1.0
>
> Which is clearly illegal, having an additional field.
>
> However, I tried encoding the space to %20, and got back to my original
> problem, i.e.
>
> Unable to determine upstream SVN information from HEAD history
>
> If I run "git-svn -n dcommit", however, it does print out a list of
> "diff-tree <sha>~1 <sha>" entries.
>
> At this point, I am pretty well stuck. Any suggestions would be much
> appreciated.
>
> Regards,
>
> Rogan Dawes
Anyone got any ideas?
Rogan
^ 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