* Make "git help" sort git commands in columns
From: Linus Torvalds @ 2005-12-18 20:41 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List, Andreas Ericsson
This changes "pretty_print_string_list()" to show the git commands
alphabetically in column order, which is the normal one.
Ie instead of doing
git commands available in '/home/torvalds/bin'
----------------------------------------------
add am ...
applypatch archimport ...
cat-file check-ref-format ...
...
it does
git commands available in '/home/torvalds/bin'
----------------------------------------------
add diff-tree ...
am fetch ...
apply fetch-pack ...
...
where each column is sorted.
This is how "ls" sorts things too, and since visually the columns are much
more distinct than the rows, so it _looks_ more sorted.
The "ls" command has a "-x" option that lists entries by lines (the way
git.c used to): if somebody wants to do that, the new print-out logic
could be easily accomodated to that too. Matter of taste and preference, I
guess.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
Side note: this is independent of the other patch I just sent out. Take
either or both.
----
diff --git a/git.c b/git.c
index c26cac6..0fd95bf 100644
--- a/git.c
+++ b/git.c
@@ -74,25 +85,28 @@ static int cmdname_compare(const void *a
static void pretty_print_string_list(struct cmdname **cmdname, int longest)
{
- int cols = 1;
+ int cols = 1, rows;
int space = longest + 1; /* min 1 SP between words */
int max_cols = term_columns() - 1; /* don't print *on* the edge */
- int i;
+ int i, j;
if (space < max_cols)
cols = max_cols / space;
+ rows = (cmdname_cnt + cols - 1) / cols;
qsort(cmdname, cmdname_cnt, sizeof(*cmdname), cmdname_compare);
- for (i = 0; i < cmdname_cnt; ) {
- int c;
+ for (i = 0; i < rows; i++) {
printf(" ");
- for (c = cols; c && i < cmdname_cnt; i++) {
- printf("%s", cmdname[i]->name);
-
- if (--c)
- mput_char(' ', space - cmdname[i]->len);
+ for (j = 0; j < cols; j++) {
+ int n = j * rows + i;
+ int size = space;
+ if (n >= cmdname_cnt)
+ break;
+ if (j == cols-1 || n + rows >= cmdname_cnt)
+ size = 1;
+ printf("%-*s", size, cmdname[n]->name);
}
putchar('\n');
}
^ permalink raw reply related
* Re: [PATCH] git-grep: convert from bash to sh
From: Timo Hirvonen @ 2005-12-18 20:18 UTC (permalink / raw)
To: Linus Torvalds; +Cc: junkio, git
In-Reply-To: <Pine.LNX.4.64.0512181155360.4827@g5.osdl.org>
On Sun, 18 Dec 2005 11:57:26 -0800 (PST)
Linus Torvalds <torvalds@osdl.org> wrote:
> On Sun, 18 Dec 2005, Timo Hirvonen wrote:
> >
> > sh does not support arrays so we have to use eval instead.
>
> This seems horribly broken.
>
> If I'm not mistaken, this breaks
>
> git grep "it's a happy coincidence"
>
> badly. I didn't test, just looking at the patch.
Actually it works:
/usr/src/linux-2.6: git grep "it's a"
Documentation/Changes:debugfs. Obviously, it's a good idea to upgrade.
Documentation/CodingStyle:and NOT read it. Burn them, it's a great
symbolic gesture.
but it doesn't work with backslashes. Need to use \\
/usr/src/linux-2.6: git grep 'e.\\n"'
Documentation/DMA-mapping.txt: "mydev: No suitable DMA
available.\n");
Documentation/DMA-mapping.txt: "mydev: No suitable DMA
available.\n");
--
http://onion.dynserv.net/~timo/
^ permalink raw reply
* Make "git help" react to window size correctly
From: Linus Torvalds @ 2005-12-18 20:15 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List, Andreas Ericsson
Currently the git "show commands" function will react to the environment
variable COLUMNS, or just default to a width of 80 characters.
That's just soo eighties. Nobody sane sets COLUMNS any more, unless they
need to support some stone-age software from before the age of steam
engines, SIGWINCH and TIOCGWINSZ.
So get with the new century, and use TIOCGWINSZ to get the terminal size.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
diff --git a/git.c b/git.c
index c26cac6..157c549 100644
--- a/git.c
+++ b/git.c
@@ -8,6 +8,7 @@
#include <errno.h>
#include <limits.h>
#include <stdarg.h>
+#include <sys/ioctl.h>
#include "git-compat-util.h"
#ifndef PATH_MAX
@@ -26,6 +27,16 @@ static int term_columns(void)
if (col_string && (n_cols = atoi(col_string)) > 0)
return n_cols;
+#ifdef TIOCGWINSZ
+ {
+ struct winsize ws;
+ if (!ioctl(1, TIOCGWINSZ, &ws)) {
+ if (ws.ws_col)
+ return ws.ws_col;
+ }
+ }
+#endif
+
return 80;
}
^ permalink raw reply related
* Re: [PATCH] git-grep: convert from bash to sh
From: Linus Torvalds @ 2005-12-18 19:57 UTC (permalink / raw)
To: Timo Hirvonen; +Cc: Junio C Hamano, git
In-Reply-To: <20051218152639.5c14bc26.tihirvon@gmail.com>
On Sun, 18 Dec 2005, Timo Hirvonen wrote:
>
> sh does not support arrays so we have to use eval instead.
This seems horribly broken.
If I'm not mistaken, this breaks
git grep "it's a happy coincidence"
badly. I didn't test, just looking at the patch.
Dammit, I'd rather depend on "bash"/"ksh" than have a broken "git grep".
Tell people to get a real shell.
Linus
^ permalink raw reply
* Re: [PATCH] git-grep: convert from bash to sh
From: Junio C Hamano @ 2005-12-18 19:37 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20051218145621.GX22159@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> I'm kind of sensitive to this stuff. I still passionately hate scp
> making me to double-quote remote filenames. It's just evil.
OK.
> --ignored|--exclude=*|\
> --exclude-from=*|\--exclude-per-directory=*)
> - git_flags=("${git_flags[@]}" "$1")
> + git_flags="$git_flags '$1'"
SQs in --exclude= or --exclude-from= parameter? E.g.
git grep --exclude-from="/cygdrive/c/pasky's patterns/cvsignore" \
-e foobar
> -A|-B|-C|-D|-d|-f|-m)
> - flags=("${flags[@]}" "$1" "$2")
> + flags="$flags '$1' '$2'"
> shift
SQs in $2 for -f. About other flags, -[ABCm] take only numbers
and -[Dd] take read/skip/recurse, so as long as your user does
not screw up you are OK. And malicious users are shooting
themselves in the foot here so we might not care too much being
loose.
> @@ -46,5 +46,6 @@ done
> [ "$pattern" ] || {
> usage
> }
> -git-ls-files -z "${git_flags[@]}" "$@" |
> - xargs -0 grep "${flags[@]}" -e "$pattern"
> +pattern="$(echo "$pattern" | sed 's/[\\"]/\\&/g')"
> +eval git-ls-files -z "$git_flags" '"$@"' |
> + eval xargs -0 grep "$flags" -e '"$pattern"'
You are not expanding $pattern in the outer shell that builds
eval arguments (letting the inner shell expand "$pattern" and
use it), so I do not think you need that sed script to muck with
it there. The eval'ed string is literally "$pattern" including
double quotes because you have sq around the last parameter to
"eval" command, and eval would do the right thing, no?
Actually the use of sed script there is actively wrong. When a
file contains these lines:
printf("%s is not there\n");
printf("\"%s\" is not there\n");
the command to pick up the second line should be:
$ git-grep -e '\\"%s\\"'
but I think your version passes \\\\\"%s\\\\\ to underlying
grep. Removing that single line would make it do the right
thing, I think.
Enough nitpicking. If you want to stay in shell and want to
avoid shell array, you would either need to be a bit more
careful if you are going to use eval, or do something like what
I originally did, which made Linus' brain shut down and had him
gouge his eyes with a spoon. It is the one that this one is a
response to:
http://marc.theaimsgroup.com/?l=git&m=112656882627760
Not that I am suggesting the latter is better than a bit more
careful 'eval' construction ;-).
I am not happy with that [@] thing either. I have the attached
laying around in my working tree --- I do not remember if I
finished it or not; it's a WIP when I thought about this issue
last time and wondered if we might be better off rewriting the
whole thing.
-- >8 --
#!/usr/bin/perl
#
# Copyright (c) 2005 Junio C Hamano
#
use strict;
my (@git_flag, @grep_flag, $pattern);
my $nargs = 100;
my (%git_ls_files_flag) =
map { '--' . $_ => 1 }
qw{cached deleted others kiled ignored
exclude= exclude-from= exclude-per-directory=};
sub is_git_flag {
my ($arg) = @_;
$arg =~ s/^([^=]*)=/$1/;
return (exists $git_ls_files_flag{$arg});
}
while (@ARGV) {
my ($arg) = shift @ARGV;
if (is_git_flag($arg)) {
push @git_flag, $arg;
}
elsif ($arg eq '-e') {
$pattern = shift @ARGV;
}
elsif ($arg =~ /^-[ABCDdfm]$/) {
push @grep_flag, $arg, (shift @ARGV);
}
elsif ($arg =~ /^--$/) {
shift @ARGV;
last;
}
elsif ($arg =~ /^-/) {
push @grep_flag, $arg;
}
elsif (! defined $pattern) {
$pattern = $arg;
last;
}
else {
last;
}
}
my $ih;
open $ih, '-|', qw(git-ls-files -z), @git_flag, @ARGV;
$/ = "\0";
my @args = ();
while (<$ih>) {
chomp;
push @args, $_;
if ($nargs <= @args) {
system 'grep', @grep_flag, '-e', $pattern, @args;
@args = ();
}
}
close $ih;
if (@args) {
system 'grep', @grep_flag, '-e', $pattern, @args;
}
^ permalink raw reply
* Re: [PATCH] diff: --abbrev option
From: Junio C Hamano @ 2005-12-18 18:35 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20051218114522.GW22159@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Ok, that's nice! :-) And if I'm going to machine-process this later,
> I can just trim the trailing dots anyway. And it seems that I can give
> --abbrev a number argument to specify the minimal abbreviation, even
> cooler! :-)
Well, it is not for machine consumption to begin with anyway.
It is an optional toy ;-).
^ permalink raw reply
* [ANNOUNCE qgit-1.0rc1]
From: Marco Costalba @ 2005-12-18 17:45 UTC (permalink / raw)
To: git
A good amount of small fixes and just few non intrusive features
added, biggest one are speed-up of ref reading at startup, a per
repository charset encoding using i18n.commitencoding git config
variable and an annotation progress bar.
I plan to relase 1.0 for end of next week, so I would like to catch
last minutes bugs with this rc1.
Thanks to Pavel and Junio for fixes and suggestions.
DOWNLOAD
Download tarball from sourceforge as usual:
http://prdownloads.sourceforge.net/qgit/qgit-1.0rc1.tar.bz2?download
Or directly from git repository:
http://digilander.libero.it/mcostalba/qgit.git
With Junio help, I setup the repository to work both with cg-clone and
git-clone and also
tags fetching is available now ;-)
INSTALLATION
You need scons and qt-mt developer libs, version 3.3.4 or better,
already installed.
qgit is NOT compatible with Qt4.
On some platforms (Debian) you should set QTDIR before to compile.
- unpack tar file
- make
- make install
qgit will be installed in $HOME/bin
CHANGELOG
- reselect current revision after a refresh or a tree filter/un-filter
- speed up startup refs reading deferring tag messages fetching
- print offending command line when running commands synchronously
- added fancy annotation progress bar
- use git variable i18n.commitencoding to store charset codec name
- converted to use git-peek-remote to read refs: slower but cleaner
- added python and perl file icons in tree view
- fix a long standing bug that filters out error reporting when a
process writes to stderr
- fix tree filtering when tree selected item is not visible
- fix error getting file sha
- add wait cursor while opening tree directory
- fix issue with mouse right-click that could freeze the UI in some cases
- always load names cache file if present
- fix graph in (rare) case of initial rev to be a fork
- fix enable/disable 'view diff' and 'view file' menus policy
- fix multi-tag commits display in status bar
- remove PGP signature from tag message
- fix file viewer sometimes opens on a wrong file when file is tree selected
Marco
___________________________________
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB
http://mail.yahoo.it
^ permalink raw reply
* Re: bad git pull
From: Nicolas Pitre @ 2005-12-18 17:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd5juub9h.fsf@assigned-by-dhcp.cox.net>
On Sat, 17 Dec 2005, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> >> I do not see much difference either way,
> >
> > ORIG suggests "origin" to me,...
>
> Hmph.
>
> I always thought it was original-head before the operation
> happened, which is why I said it is no different from
> previous-head.
OK I agree.
Nicolas
^ permalink raw reply
* Re: [PATCH] git-grep: convert from bash to sh
From: Petr Baudis @ 2005-12-18 14:56 UTC (permalink / raw)
To: Timo Hirvonen; +Cc: Junio C Hamano, git
In-Reply-To: <20051218152639.5c14bc26.tihirvon@gmail.com>
Dear diary, on Sun, Dec 18, 2005 at 02:26:39PM CET, I got a letter
where Timo Hirvonen <tihirvon@gmail.com> said that...
> sh does not support arrays so we have to use eval instead.
>
> Signed-off-by: Timo Hirvonen <tihirvon@gmail.com>
This version also makes it work properly with patterns containing quotes
and backslashes (not so unusual when you grep for C strings).
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
I'm kind of sensitive to this stuff. I still passionately hate scp
making me to double-quote remote filenames. It's just evil.
diff --git a/git-grep.sh b/git-grep.sh
index 2ed8e95..7e9e5bf 100755
--- a/git-grep.sh
+++ b/git-grep.sh
@@ -8,21 +8,21 @@ SUBDIRECTORY_OK='Yes'
. git-sh-setup
pattern=
-flags=()
-git_flags=()
+flags=
+git_flags=
while : ; do
case "$1" in
--cached|--deleted|--others|--killed|\
--ignored|--exclude=*|\
--exclude-from=*|\--exclude-per-directory=*)
- git_flags=("${git_flags[@]}" "$1")
+ git_flags="$git_flags '$1'"
;;
-e)
pattern="$2"
shift
;;
-A|-B|-C|-D|-d|-f|-m)
- flags=("${flags[@]}" "$1" "$2")
+ flags="$flags '$1' '$2'"
shift
;;
--)
@@ -31,7 +31,7 @@ while : ; do
break
;;
-*)
- flags=("${flags[@]}" "$1")
+ flags="$flags '$1'"
;;
*)
if [ -z "$pattern" ]; then
@@ -46,5 +46,6 @@ done
[ "$pattern" ] || {
usage
}
-git-ls-files -z "${git_flags[@]}" "$@" |
- xargs -0 grep "${flags[@]}" -e "$pattern"
+pattern="$(echo "$pattern" | sed 's/[\\"]/\\&/g')"
+eval git-ls-files -z "$git_flags" '"$@"' |
+ eval xargs -0 grep "$flags" -e '"$pattern"'
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply related
* Re: [PATCH] cg-completion: improve options and command listing
From: Jonas Fonseca @ 2005-12-18 14:34 UTC (permalink / raw)
To: Ben Clifford; +Cc: Git List, Petr Baudis
In-Reply-To: <EF827EE8-7B7A-4D19-A08D-8C67D6B74195@hawaga.org.uk>
Ben Clifford <benc@hawaga.org.uk> wrote Sun, Dec 18, 2005:
>
> On 12 Dec 2005, at 04:39, Jonas Fonseca wrote:
>
> >Complete help options and improve filtering for command name
> >completion.
> >
> >Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
> >
>
> Hi. I've applied this patch to the dev branch cg-compl in my
> gitcompletion repo.
>
> I'm interested by what you mean by 'all sorts of garbage' - it seems
> ok on my machine.
~/src/cogito/cogito > __cg_cmdlist | head
cg-add Add files to the GIT repository.
cg-clean Clean unknown files from the working tree.
cg-clone Clone a remote GIT repository.
cg-commit Commit into a GIT repository.
cg-diff Make a diff between two GIT trees.
cg-export Exports a particular revision from a GIT repository.
cg-fetch Fetch changes from a remote branch to the local GIT repository.
cg-help Show help for Cogito commands.
cg-init Initialize a GIT repository.
cg-log Make a log of changes in a GIT branch.
Else I was thinking of maybe adding --list parameter to cg-help to have
it list all known commands.
--
Jonas Fonseca
^ permalink raw reply
* [PATCH] git-grep: convert from bash to sh
From: Timo Hirvonen @ 2005-12-18 13:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
sh does not support arrays so we have to use eval instead.
Signed-off-by: Timo Hirvonen <tihirvon@gmail.com>
---
git-grep.sh | 14 +++++++-------
1 files changed, 7 insertions(+), 7 deletions(-)
11c29a066288c5f05a67ff0d46e9ce17cd7a37da
diff --git a/git-grep.sh b/git-grep.sh
index 2ed8e95..2f0a297 100755
--- a/git-grep.sh
+++ b/git-grep.sh
@@ -8,21 +8,21 @@ SUBDIRECTORY_OK='Yes'
. git-sh-setup
pattern=
-flags=()
-git_flags=()
+flags=
+git_flags=
while : ; do
case "$1" in
--cached|--deleted|--others|--killed|\
--ignored|--exclude=*|\
--exclude-from=*|\--exclude-per-directory=*)
- git_flags=("${git_flags[@]}" "$1")
+ git_flags="$git_flags '$1'"
;;
-e)
pattern="$2"
shift
;;
-A|-B|-C|-D|-d|-f|-m)
- flags=("${flags[@]}" "$1" "$2")
+ flags="$flags '$1' '$2'"
shift
;;
--)
@@ -31,7 +31,7 @@ while : ; do
break
;;
-*)
- flags=("${flags[@]}" "$1")
+ flags="$flags '$1'"
;;
*)
if [ -z "$pattern" ]; then
@@ -46,5 +46,5 @@ done
[ "$pattern" ] || {
usage
}
-git-ls-files -z "${git_flags[@]}" "$@" |
- xargs -0 grep "${flags[@]}" -e "$pattern"
+eval git-ls-files -z "$git_flags" '"$@"' |
+ eval xargs -0 grep "$flags" -e '"$pattern"'
--
0.99.9.GIT
^ permalink raw reply related
* Re: [PATCH] diff: --abbrev option
From: Petr Baudis @ 2005-12-18 11:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vek4byuwg.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Sun, Dec 18, 2005 at 03:57:19AM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Petr Baudis <pasky@suse.cz> writes:
>
> > I was actually thinking to by default trim all the hashes Cogito show
> > to 12 or 16 characters. Seven still seems dangerously low to me, though;
> > it would be nice if the number of characters to trim would be
> > configurable (unless I've missed that).
>
> Well, I did better than you imagined this time, for a change ;-)
> It trims and adds extra as needed without breaking alignments,
> so you could get something like this:
>
> > :100755 100755 0266f46... b0e54ed... M git-branch.sh
> > :100755 100755 f241d4b9.. 36308d2ab. M git-checkout.sh
>
> That is, ... is not just distraction but are part of the
> design. Cut and paste is a byproduct.
Ok, that's nice! :-) And if I'm going to machine-process this later,
I can just trim the trailing dots anyway. And it seems that I can give
--abbrev a number argument to specify the minimal abbreviation, even
cooler! :-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: bad git pull
From: Junio C Hamano @ 2005-12-18 7:15 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0512172310060.26663@localhost.localdomain>
Nicolas Pitre <nico@cam.org> writes:
>> I do not see much difference either way,
>
> ORIG suggests "origin" to me,...
Hmph.
I always thought it was original-head before the operation
happened, which is why I said it is no different from
previous-head.
^ permalink raw reply
* Re: new file leaked onto release branch
From: Junio C Hamano @ 2005-12-18 7:08 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Brown, Len, git
In-Reply-To: <Pine.LNX.4.64.0512141150210.3292@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> git-merge does:
>
> common=$(git-merge-base --all $head "$@")
>
> and then it _should_ have triggered this case:
>
> case "$#,$common,$no_commit" in
> ..
> 1,"$1",*)
> # If head can reach all the merge then we are up to date.
> # but first the most common case of merging one remote
> echo "Already up-to-date."
> dropsave
> exit 0
> ;;
> ..
>
> and thus never have created any merge messages.
>...
> Hmm. It really looks like it should have been impossible to generate that
> commit with current git, which is why I'm still a bit suspicious.
Two good news (one puzzle fully explained, one bug fixed) and
one not so good news (one puzzle still remains).
First good news. I solved this puzzle. This has been fixed as
a part of a seemingly independent fix:
commit 9954f5b876abb6118f9bdf1d113239d86acca7bd
Author: Junio C Hamano <junkio@cox.net>
Date: Tue Dec 13 17:01:23 2005 -0800
[PATCH] allow merging any committish
Although "git-merge" is advertised as the end-user level command
(instead of being a "git-pull" backend), it was not prepared to
take tag objects that point at commits and barfed when fed one.
Sanitize the input while we validate them, for which we already
have a loop.
Signed-off-by: Junio C Hamano <junkio@cox.net>
There was a bug in git-merge which used the user input without
converting them to object names. When the part you quoted above
was executed, $1..${$#} were remote ref parameters from the
command line, so in the case of Len's commit, which did:
git merge "Auto-update from upstream" release linus
"$1" at that point was string "linus", not the object name
returned from "git-rev-parse --verify linus". The case pattern
match did not match because $common was object name and $1 was
not. This was fixed by the above commit; the user supplied refs
are already converted into object names at that point with the
current code.
I have never seen this problem myself because git-pull feeds
object names after converting refnames to git-merge, but people
who used the git-merge command themselves could have been
affected by the bug.
So I think I am done with the "this is "already-up-to-date"; why
does that commit exists in the first place?" commit we have
discussed in this thread.
Second good news. I have been working on a theory on the "where
did this file come from?" problem. I found a real bug that can
cause a bad mismerge that can introduce completely unrelated
changes to the tree, but after digging a bit deeper, I do not
think it matches Len's problematic commit. It still is a bug.
If you run the sequence attached at the end in an empty
repository, you will have a repository suitable for this
demonstration. After the script runs, the commit structure
would look like this:
! [heads/7589] add xyzzy
* [master] Merge 7589 branch
! [nitfol] add nitfol
---
+ [8eec60c] add xyzzy <tag 7589>
+ [db5bc99] edit frotz
+ [758916c] add nitfol
+++ [70c4319] initial
There are three branches: master, nitfol, and "7589".
They all start from the initial commit which has one file
"frotz" and each branch adds one commit. Also the tip of 7589
branch is tagged as "7589". Now, we will run this:
$ git merge "Merge 7589 branch" HEAD 7589
With this setup, the current tip of the "master" branch
mismerges and adds "nitfol" file which did not exist in either
branch heads (and it is not fixed with the 9954f5 commit above).
A change I introduced mid November causes get_sha1_basic() to
misinterpret "7589" to be neither the tag 7589 nor branch 7589
tip, but by mistake it does not outright fail, but returns the
758916c commit! This merge ends up pulling nitfol branch head
into master branch, not 7589 branch as the user intended. The
resulting merge commit has db5bc99 and 758916c as its parents.
The "revert misguided disambiguation" patch I posted earlier
fixes this problem. I'll push it out tonight.
This theory however does not seem to match what really happened.
Len did mention that he has "5165" branch (there is a commit
marked "Pull 5165 into release branch" near a problematic
merge), but he did not say he also has a 5165 tag; the bug does
not trigger if you do not have the tag of the same name. Also
if this theory holds true, the problematic commit should have a
commit whose object name begins with 5165 as the second parent
but that is not the case. And the problem happened with a
commit that is not a merge between release/test and topic
branch anyway; it is with an "Auto-update from upstream" commit.
So I am still puzzled by the "where did this file come from"
problem. The most plausible explanation was the driver error
mentioned already in the thread: "update-index --add" in the
middle of merge with manual committing.
----------------------------------------------------------------
#!/bin/sh
GIT_AUTHOR_DATE='1995-01-29T15:00:00 -0800'
GIT_AUTHOR_EMAIL='author@example.com'
GIT_AUTHOR_NAME='A U Thor'
GIT_COMMITTER_DATE='1995-01-29T15:00:00 -0800'
GIT_COMMITTER_EMAIL='committer@example.com'
GIT_COMMITTER_NAME='C O Mmitter'
export GIT_AUTHOR_DATE
export GIT_AUTHOR_EMAIL
export GIT_AUTHOR_NAME
export GIT_COMMITTER_DATE
export GIT_COMMITTER_EMAIL
export GIT_COMMITTER_NAME
git init-db
echo frotz >frotz
git add frotz
git commit -m 'initial'
git checkout -b nitfol
echo nitfol >nitfol
git add nitfol
git commit -m 'add nitfol'
git checkout -b 7589 master
echo xyzzy >xyzzy
git add xyzzy
git commit -m 'add xyzzy'
git tag 7589
git checkout master
echo FROTZ >frotz
git update-index frotz
git commit -m 'edit frotz'
^ permalink raw reply
* Re: bad git pull
From: Linus Torvalds @ 2005-12-18 6:31 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0512172310060.26663@localhost.localdomain>
On Sat, 17 Dec 2005, Nicolas Pitre wrote:
>
> ORIG suggests "origin" to me
It's meant to be short for ORIGinal, not ORIGin. That's how I wrote it and
have always read it ;)
Linus
^ permalink raw reply
* Re: bad git pull
From: Nicolas Pitre @ 2005-12-18 4:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7v8xujyuna.fsf@assigned-by-dhcp.cox.net>
On Sat, 17 Dec 2005, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > One observation is that ORIG_HEAD should probably be named PREV_HEAD in
> > such context to make it more obvious what it is about.
>
> I do not see much difference either way,
ORIG suggests "origin" to me, something that was there first, or before
anything else. If you want to undo something, you want its "previous"
state restored relative to the current state, not the absolute previous
(first) one.
> but I suspect ORIG_HEAD
> is pretty much well established by now.
Well, cogito for one doesn't care at all, and it even doesn't make for
it to be created/updated.
But still it can remain for what it is now, and PREV_HEAD added for undo
purpose.
Not a big deal in any case though.
Nicolas
^ permalink raw reply
* Re: [PATCH] Remove misguided branch disambiguation.
From: Junio C Hamano @ 2005-12-18 3:03 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20051218000636.GA20874@steel.home>
Alex Riesen <raa.lkml@gmail.com> writes:
> Right. The test 'Ambiguous' in t0000-basic is redundant now, btw
I reverted that in jc/tail branch (part of pu branch) as well.
^ permalink raw reply
* Re: bad git pull
From: Junio C Hamano @ 2005-12-18 3:02 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Linus Torvalds, git
In-Reply-To: <Pine.LNX.4.64.0512171601430.26663@localhost.localdomain>
Nicolas Pitre <nico@cam.org> writes:
> One observation is that ORIG_HEAD should probably be named PREV_HEAD in
> such context to make it more obvious what it is about.
I do not see much difference either way, but I suspect ORIG_HEAD
is pretty much well established by now.
^ permalink raw reply
* Re: [PATCH] diff: --abbrev option
From: Junio C Hamano @ 2005-12-18 2:57 UTC (permalink / raw)
To: git
In-Reply-To: <20051218001756.GS22159@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> I was actually thinking to by default trim all the hashes Cogito show
> to 12 or 16 characters. Seven still seems dangerously low to me, though;
> it would be nice if the number of characters to trim would be
> configurable (unless I've missed that).
Well, I did better than you imagined this time, for a change ;-)
It trims and adds extra as needed without breaking alignments,
so you could get something like this:
> :100755 100755 0266f46... b0e54ed... M git-branch.sh
> :100755 100755 f241d4b9.. 36308d2ab. M git-checkout.sh
That is, ... is not just distraction but are part of the
design. Cut and paste is a byproduct.
^ permalink raw reply
* Re: How to clone-pack the HEAD?
From: Petr Baudis @ 2005-12-18 0:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfyouricc.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Thu, Dec 15, 2005 at 07:21:23AM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Junio C Hamano <junkio@cox.net> writes:
>
> > Also I might want to give --keep option to fetch-pack as well;
> > clone-pack has some static functions that we can extract out to
> > a common file to link to both.
>
> And this is the second installment, on top of the previous one.
> I am a bit reluctant about this one only because of its size,
> but I suspect it may be much easier to use for your purpose.
>
> I'll keep this in the proposed updates branch for now (the other
> one goes to master tonight), so if you like this one, please
> holler, test out and ack.
Well, I like this one, but you don't need to put this to master just for
me, I'm perfectly fine with the git-clone-pack fix - both commands are
now equally simple for me to use in Cogito. (And both seem to work fine
after some basic testing.)
But you are right that git-clone-pack is basically made obsolete by this
patch, and I tend to like that fact - that's why I have slight
preference to this patch anyway, despite its size (and it's mostly
common code being moved around anyway). It's probably too late to remove
git-clone-pack altogether, but you might at least deprecate it and print
a warning when it's being ran (or at least please print a warning when
it's being ran in a repository which is already populated, which is very
likely a driver error, and I've actually made it just a minute ago ;).
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: [PATCH] cg-completion: improve options and command listing
From: Ben Clifford @ 2005-12-17 23:25 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: Git List, Petr Baudis
In-Reply-To: <20051211190931.GF2960@diku.dk>
On 12 Dec 2005, at 04:39, Jonas Fonseca wrote:
> Complete help options and improve filtering for command name
> completion.
>
> Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
>
Hi. I've applied this patch to the dev branch cg-compl in my
gitcompletion repo.
I'm interested by what you mean by 'all sorts of garbage' - it seems
ok on my machine.
Ben
> ---
>
> The current filtering causes all sorts of garbage to be listed in the
> command listing.
>
> commit f0535e9952f1cace89d03649e8238aca69a6df44
> tree e05dfadb63bd92ead0dc29d326065b7a797e2109
> parent 3c14cded46e110396127fc5b5e65883eb5cd60b9
> author Jonas Fonseca <fonseca@diku.dk> Wed, 07 Dec 2005 20:58:50 +0100
> committer Jonas Fonseca <fonseca@antimatter.localdomain> Wed, 07
> Dec 2005 20:58:50 +0100
--
Ben • ベン • Бэн • 벤 • 班明
http://www.hawaga.org.uk/ben/
My email is high latency but best way to contact me. Alternatively,
SMS number(s) at above URL.
^ permalink raw reply
* Re: How to clone-pack the HEAD?
From: Petr Baudis @ 2005-12-18 0:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpsnzq66x.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Thu, Dec 15, 2005 at 06:29:10AM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Junio C Hamano <junkio@cox.net> writes:
>
> > Not really. I take this back. What you want to do I did not
> > understand well enough.
> >
> > HEAD is kinda special. A hack I can think of is to do ls-remote
> > first and do the guess clone-pack does for full clone case, and
> > then give a specific branch name to clone. That might work.
>
> ... and another way would be to do this; I'll put this (with
> fixes if there is some needed) in "master" tonight.
Thanks! This makes it work very nicely and exactly the way I want, even
giving git-fetch-pack-compatible output so I can seamlessly switch
between the two commands. Very nice!
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: [PATCH] diff: --abbrev option
From: Petr Baudis @ 2005-12-18 0:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3bks12n6.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Sat, Dec 17, 2005 at 10:41:49AM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> When I show transcripts to explain how something works, I often
> find myself hand-editing the diff-raw output to shorten various
> object names in the output.
>
> This adds --abbrev option to the diff family, which shortens
> diff-raw output and diff-tree commit id headers.
>
> Signed-off-by: Junio C Hamano <junkio@cox.net>
>
> ---
>
> * Earlier I announced that I have this toy in proposed updates
> without actually showing the code, so here it is. I have
> added code to find unique abbreviation as well. It is
> primarily useful to quote things in e-mail, like this:
>
> $ git-rev-parse master | git-diff-tree --pretty -r --abbrev --stdin
> diff-tree 01385e2... (from 6922471...)
> Author: Junio C Hamano <junkio@cox.net>
> Date: Fri Dec 16 23:12:33 2005 -0800
>
> Comment fixes.
>
> Signed-off-by: Junio C Hamano <junkio@cox.net>
>
> :100755 100755 0266f46... b0e54ed... M git-branch.sh
> :100755 100755 f241d4b... 36308d2... M git-checkout.sh
I think the '...' is just distracting. It makes cut'n'paste more
difficult, and it's usually fairly obvious that this is start of a hash,
and that the hash might not be complete.
I was actually thinking to by default trim all the hashes Cogito show
to 12 or 16 characters. Seven still seems dangerously low to me, though;
it would be nice if the number of characters to trim would be
configurable (unless I've missed that).
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: [PATCH] Remove misguided branch disambiguation.
From: Alex Riesen @ 2005-12-18 0:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7virto12u5.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano, Sat, Dec 17, 2005 10:37:38 +0100:
> This removes the misguided attempt to refuse processing a branch
> name xyzzy and insist it to be given as either heads/xyzzy or
> tags/xyzzy when a tag xyzzy exists. There was no reason to do
> so --- the search order was predictable and well defined, so if
> the user says xyzzy we should have taken the tag xyzzy in such a
> case without complaining.
Right. The test 'Ambiguous' in t0000-basic is redundant now, btw
^ permalink raw reply
* Re: bad git pull
From: Nicolas Pitre @ 2005-12-17 21:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7v4q582htm.fsf@assigned-by-dhcp.cox.net>
On Sat, 17 Dec 2005, Junio C Hamano wrote:
> Linus Torvalds <torvalds@osdl.org> writes:
>
> > That said, I think a lot of newbies might want to have a "git undo", and
> > not because of any BK history. Even if it just ends up being nothing but
> > shorthand for "git reset --hard ORIG_HEAD".
>
> I agree to this in principle, but I am afraid "git undo" is too
> generic and fuzzy a term. Things you might possibly want to
> undo depends on what you did last [*1*]. In most undoable
> cases, "reset --hard" is almost right but most likely would
> result in information loss.
One observation is that ORIG_HEAD should probably be named PREV_HEAD in
such context to make it more obvious what it is about.
Nicolas
^ 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