* Re: [PATCH] pack.indexversion config option now defaults to 2
From: Junio C Hamano @ 2008-06-25 19:19 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Linus Torvalds, git
In-Reply-To: <alpine.LFD.1.10.0806251442500.2979@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> On Tue, 24 Jun 2008, Junio C Hamano wrote:
> ...
> Actually the first release to support this is v1.4.4 not v1.5.0.
>
>> I am basing the above 1.5.0 on description of b6945f5 (git-repack:
>> repo.usedeltabaseoffset, 2006-10-13).
>
> $ git describe --contains b6945f5
> v1.4.4-rc1~77^2~2
I know, as I did that myself; but I wanted to be conservative and gave a
release after a major release bump.
>> On the "indexVersion" change, the documentation reads:
>>
>> pack.indexVersion::
>> Specify the default pack index version. Valid values are 1 for
>> legacy pack index used by Git versions prior to 1.5.2, and 2 for
>> the new pack index with capabilities for packs larger than 4 GB
>> as well as proper protection against the repacking of corrupted
>> + packs. Version 2 is the default. Note that version 2 is enforced
>> + and this config option ignored whenever the corresponding pack is
>> + larger than 2 GB.
>>
>> which lacks the recovery insn (and it is int strictly the fault of this
>> patch, but we should have done this when we introduced the v2 idx). I
>> think a separate paragraph after the above would be necessary and
>> sufficient:
>>
>> If you have an ancient git that does not understand the version 2
>> `*.idx` file, cloning or fetching over a non native protocol
>> (e.g. "http" and "rsync") which will copy both `*.pack` file and
>> corresponding `*.idx` file from the other side may give you a
>> repository that cannot be accessed with your old git. If the
>> `*.pack` file is smaller than 2 GB, however, you can use
>> `git-index-pack` on the `*.pack` to regenerate the `*.idx` file.
>
> Looks fine to me. Will you amend the patches or do you want me to
> repost them?
No worries. After re-reading what you wrote I think both are fine as they
are. I do not mind adding the above 7 lines to the indexVersion one
myself.
^ permalink raw reply
* Re: update-index --assume-unchanged doesn't make things go fast
From: Jakub Narebski @ 2008-06-25 19:30 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Git Mailing List
In-Reply-To: <32541b130806250944x717cf609x7aa520c77a7c6911@mail.gmail.com>
"Avery Pennarun" <apenwarr@gmail.com> writes:
> Hi all,
>
> Using git 1.5.6.64.g85fe, but this applies to various other versions
> I've tried.
>
> I have a git repo with about 17000+ files in 1000+ directories. In
> Linux, "git status" runs in under a second, which is perfectly fine.
> But on Windows, which can apparently only stat() about 1000 files per
> second, "git status" takes at least 17 seconds to run, even with a hot
> cache. (I've confirmed that stat() is so slow on Windows by writing a
> simple program that just runs stat() in a tight loop. The slowness
> may be cygwin-related, as I found some direct Win32 calls that seem to
> go more than twice as fast... which is still too slow.)
Which git version do you use? Does it have the following configuration
variable (also available as command option):
status.showUntrackedFiles::
By default, linkgit:git-status[1] and linkgit:git-commit[1] show
files which are not currently tracked by Git. Directories which
contain only untracked files, are shown with the directory name
only. Showing untracked files means that Git needs to lstat() all
all the files in the whole repository, which might be slow on some
systems. So, this variable controls how the commands displays
the untracked files. Possible values are:
- 'no' - Show no untracked files
- 'normal' - Shows untracked files and directories
- 'all' - Shows also individual files in untracked directories.
HTH.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [Bug] for-each-ref: %(object) and %(type) unimplemented
From: Junio C Hamano @ 2008-06-25 19:38 UTC (permalink / raw)
To: Mikael Magnusson; +Cc: Jeff King, Lea Wiemann, Junio C Hamano, Git Mailing List
In-Reply-To: <237967ef0806251208u65c17652gc6091da98294f807@mail.gmail.com>
"Mikael Magnusson" <mikachu@gmail.com> writes:
> 2008/6/25 Jeff King <peff@peff.net>:
>> On Wed, Jun 25, 2008 at 12:08:15PM -0400, Jeff King wrote:
>>
>>> Since you seem to be testing for-each-ref, maybe it would make sense to
>>> put together a test script that exercises each of the atoms?
>>
>> Hmm. Actually, there is a test in t6300 that runs with each atom name.
>> Unfortunately, it doesn't bother actually checking the output for
>> sanity, so the fact that these atoms returned the empty string was
>> missed.
>
> The documentation also says "tree" and "parent" should work (which they
> also don't).
The doc does not say any such thing. A tag object does not have 'parent'
nor 'tree' header fields.
Neither a commit have 'object' nor 'type' header fields and you cannot ask
for them when showing a commit object.
^ permalink raw reply
* Re: update-index --assume-unchanged doesn't make things go fast
From: Junio C Hamano @ 2008-06-25 19:41 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Avery Pennarun, Git Mailing List
In-Reply-To: <m33an1josg.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
> "Avery Pennarun" <apenwarr@gmail.com> writes:
>
>> Hi all,
>>
>> Using git 1.5.6.64.g85fe, but this applies to various other versions
>> I've tried.
>>
>> I have a git repo with about 17000+ files in 1000+ directories. In
>> Linux, "git status" runs in under a second, which is perfectly fine.
>> But on Windows, which can apparently only stat() about 1000 files per
>> second, "git status" takes at least 17 seconds to run, even with a hot
>> cache. (I've confirmed that stat() is so slow on Windows by writing a
>> simple program that just runs stat() in a tight loop. The slowness
>> may be cygwin-related, as I found some direct Win32 calls that seem to
>> go more than twice as fast... which is still too slow.)
>
> Which git version do you use? Does it have the following configuration
> variable (also available as command option):
>
> status.showUntrackedFiles::
> By default, linkgit:git-status[1] and linkgit:git-commit[1] show
> files which are not currently tracked by Git. Directories which
> contain only untracked files, are shown with the directory name
> only. Showing untracked files means that Git needs to lstat() all
> all the files in the whole repository, which might be slow on some
> systems. So, this variable controls how the commands displays
> the untracked files. Possible values are:
>
> - 'no' - Show no untracked files
> - 'normal' - Shows untracked files and directories
> - 'all' - Shows also individual files in untracked directories.
That's on 'master' progressing forward to eventually become 1.6.0.
^ permalink raw reply
* [PATCH] git-send-email: add support for TLS via Net::SMTP::SSL
From: Thomas Rast @ 2008-06-25 19:42 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Thomas Rast
We do this by handing over the Net::SMTP instance to Net::SMTP::SSL,
which avoids Net::SMTP::TLS and its weird error checking. This trick
is due to Brian Evins.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
The SMTP at my university only works with TLS, so I needed this. The
trick referred to above was posted here:
http://kerneltrap.org/mailarchive/git/2007/10/31/374810
- Thomas
Documentation/git-send-email.txt | 16 ++++++++++++----
git-send-email.perl | 33 ++++++++++++++++++++++++++++-----
2 files changed, 40 insertions(+), 9 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 251d661..dc7eb7b 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -133,10 +133,13 @@ or on the command line. If a username has been specified (with
specified (with --smtp-pass or a configuration variable), then the
user is prompted for a password while the input is masked for privacy.
+--smtp-encryption::
+ Specify the encryption to use, either 'ssl' or 'tls'. Any other
+ value reverts to plain SMTP. Default is the value of
+ 'sendemail.smtpencryption'.
+
--smtp-ssl::
- If set, connects to the SMTP server using SSL.
- Default is the value of the 'sendemail.smtpssl' configuration value;
- if that is unspecified, does not use SSL.
+ Legacy alias for '--smtp-encryption=ssl'.
--subject::
Specify the initial subject of the email thread.
@@ -229,8 +232,13 @@ sendemail.smtpuser::
sendemail.smtppass::
Default SMTP-AUTH password.
+sendemail.smtpencryption::
+ Default encryption method. Use 'ssl' for SSL (and specify an
+ appropriate port), or 'tls' for TLS. Takes precedence over
+ 'smtpssl' if both are specified.
+
sendemail.smtpssl::
- Boolean value specifying the default to the '--smtp-ssl' parameter.
+ Legacy boolean that sets 'smtpencryption=ssl' if enabled.
Author
------
diff --git a/git-send-email.perl b/git-send-email.perl
index 0b04ba3..7630720 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -84,7 +84,10 @@ Options:
--smtp-pass The password for SMTP-AUTH.
- --smtp-ssl If set, connects to the SMTP server using SSL.
+ --smtp-encryption Specify 'tls' for STARTTLS encryption, or 'ssl' for SSL.
+ Any other value disables the feature.
+
+ --smtp-ssl Synonym for '--smtp-encryption=ssl'. Deprecated.
--suppress-cc Suppress the specified category of auto-CC. The category
can be one of 'author' for the patch author, 'self' to
@@ -184,7 +187,7 @@ my ($quiet, $dry_run) = (0, 0);
# Variables with corresponding config settings
my ($thread, $chain_reply_to, $suppress_from, $signed_off_cc, $cc_cmd);
-my ($smtp_server, $smtp_server_port, $smtp_authuser, $smtp_ssl);
+my ($smtp_server, $smtp_server_port, $smtp_authuser, $smtp_encryption);
my ($identity, $aliasfiletype, @alias_files, @smtp_host_parts);
my ($no_validate);
my (@suppress_cc);
@@ -194,7 +197,6 @@ my %config_bool_settings = (
"chainreplyto" => [\$chain_reply_to, 1],
"suppressfrom" => [\$suppress_from, undef],
"signedoffcc" => [\$signed_off_cc, undef],
- "smtpssl" => [\$smtp_ssl, 0],
);
my %config_settings = (
@@ -249,7 +251,8 @@ my $rc = GetOptions("sender|from=s" => \$sender,
"smtp-server-port=s" => \$smtp_server_port,
"smtp-user=s" => \$smtp_authuser,
"smtp-pass:s" => \$smtp_authpass,
- "smtp-ssl!" => \$smtp_ssl,
+ "smtp-ssl" => sub { $smtp_encryption = 'ssl' },
+ "smtp-encryption=s" => \$smtp_encryption,
"identity=s" => \$identity,
"compose" => \$compose,
"quiet" => \$quiet,
@@ -289,6 +292,15 @@ sub read_config {
$$target = Git::config(@repo, "$prefix.$setting") unless (defined $$target);
}
}
+
+ if (!defined $smtp_encryption) {
+ my $enc = Git::config(@repo, "$prefix.smtpencryption");
+ if (defined $enc) {
+ $smtp_encryption = $enc;
+ } elsif (Git::config_bool(@repo, "$prefix.smtpssl")) {
+ $smtp_encryption = 'ssl';
+ }
+ }
}
# read configuration from [sendemail "$identity"], fall back on [sendemail]
@@ -738,7 +750,7 @@ X-Mailer: git-send-email $gitversion
die "The required SMTP server is not properly defined."
}
- if ($smtp_ssl) {
+ if ($smtp_encryption eq 'ssl') {
$smtp_server_port ||= 465; # ssmtp
require Net::SMTP::SSL;
$smtp ||= Net::SMTP::SSL->new($smtp_server, Port => $smtp_server_port);
@@ -748,6 +760,17 @@ X-Mailer: git-send-email $gitversion
$smtp ||= Net::SMTP->new((defined $smtp_server_port)
? "$smtp_server:$smtp_server_port"
: $smtp_server);
+ if ($smtp_encryption eq 'tls') {
+ require Net::SMTP::SSL;
+ $smtp->command('STARTTLS');
+ $smtp->response();
+ if ($smtp->code == 220) {
+ $smtp = Net::SMTP::SSL->start_SSL($smtp)
+ or die "STARTTLS failed! ".$smtp->message;
+ } else {
+ die "Server does not support STARTTLS! ".$smtp->message;
+ }
+ }
}
if (!$smtp) {
--
1.5.6.84.ge5c1
^ permalink raw reply related
* Re: [PATCH] cmd_reset: don't trash uncommitted changes unless told to
From: Theodore Tso @ 2008-06-25 19:50 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Johannes Sixt, Boaz Harrosh, Steven Walter,
git, jeske
In-Reply-To: <7v63rx2zwf.fsf@gitster.siamese.dyndns.org>
On Wed, Jun 25, 2008 at 10:22:08AM -0700, Junio C Hamano wrote:
> Isn't that this?
>
> #!/bin/sh
> exec git checkout HEAD -- "$@"
Well, I think you really want this to handle filenames with spaces:
for i in $*
do
git checkout HEAD -- "$i"
done
I still think it would be nice this as a built-in for "git
revert-file" since this is much easier to type than "git checkout HEAD
-- " (all those characters and capital letters). But if it ends up
being a private shell script for people who do this a lot, that's also fine.
I will say that it was not at all obvious that "git checkout" can also
be used to revert files, so it wasn't one of the man pages that looked
for when trying to figure out how to implement revert files. That's
why I ended up using:
git show HEAD:$prefix$i > $i
- Ted
^ permalink raw reply
* Re: update-index --assume-unchanged doesn't make things go fast
From: Avery Pennarun @ 2008-06-25 19:53 UTC (permalink / raw)
To: Jakub Narebski, Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <m33an1josg.fsf@localhost.localdomain>
On 6/25/08, Jakub Narebski <jnareb@gmail.com> wrote:
> Which git version do you use? Does it have the following configuration
> variable (also available as command option):
>
> status.showUntrackedFiles::
> [...]
Thanks, I didn't know about that one. Using that definitely makes
"git status" go much faster (pretty much instantaneous if I've also
used --assume-unchanged on everything).
Now the catch is, if I want to implement the daemon I was talking
about earlier, I'd like to be able to notice untracked files (or
directories with untracked files) individually. Ideally, I guess the
best way would be to just keep a separate list of all existing files
that aren't in the index, and have git status look at that rather than
at the actual filesystem.
Are there any suggestions for how best to do this?
Thanks,
Avery
^ permalink raw reply
* Re: [PATCH] cmd_reset: don't trash uncommitted changes unless told to
From: Avery Pennarun @ 2008-06-25 20:04 UTC (permalink / raw)
To: Theodore Tso
Cc: Junio C Hamano, Johannes Schindelin, Johannes Sixt, Boaz Harrosh,
Steven Walter, git, jeske
In-Reply-To: <20080625195003.GB15077@mit.edu>
On 6/25/08, Theodore Tso <tytso@mit.edu> wrote:
> On Wed, Jun 25, 2008 at 10:22:08AM -0700, Junio C Hamano wrote:
> > exec git checkout HEAD -- "$@"
>
> Well, I think you really want this to handle filenames with spaces:
>
> for i in $*
> do
> git checkout HEAD -- "$i"
> done
"$@" notation actually handles spaces just fine. It's magic that way.
On the other hand, "for i in $*" does not, because all the spaces get
split as part of the unquoted $* in "for". Beware!
> I still think it would be nice this as a built-in for "git
> revert-file" since this is much easier to type than "git checkout HEAD
> -- " (all those characters and capital letters). But if it ends up
> being a private shell script for people who do this a lot, that's also fine.
How about making "git checkout" default to HEAD if no revision is
supplied? There's precedent for this in, say, git-diff (and I think a
few others).
Incidentally, "checkout <filename>" was also the way to do a revert
operation in CVS. And the way to switch branches, too, iirc. So git
isn't being too unusual here. That said, the commands were
deliberately renamed in svn because CVS was considered largely insane.
Have fun,
Avery
^ permalink raw reply
* Re: [PATCH 2/2] update-hook-example: optionally allow non-fast-forward
From: Junio C Hamano @ 2008-06-25 20:04 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: git
In-Reply-To: <1214382416-6687-2-git-send-email-dpotapov@gmail.com>
Dmitry Potapov <dpotapov@gmail.com> writes:
> Sometimes it is desirable to have non-fast-forward branches in a
> shared repository. A typical example of that is the 'pu' branch.
> This patch extends the format of allowed-users and allow-groups
> files by using the '+' sign at the beginning as the mark that
> non-fast-forward pushes are permitted to the branch.
Thanks. 1/2 queued for 'maint' (as it was an obvious fix) to be included
in 1.5.6.1, but not this one that is a feature enhancement even though it
is in docs.
> Signed-off-by: Dmitry Potapov <dpotapov@gmail.com>
> rc=$(cat $allowed_users_file | grep -v '^#' | grep -v '^$' |
> while read head_pattern user_patterns; do
> - matchlen=$(expr "$1" : "$head_pattern")
> - if [ "$matchlen" == "${#1}" ]; then
> + matchlen=$(expr "$1" : "${head_pattern#+}")
> + allow_noff=$(expr substr "$head_pattern" 1 1)
> + if [ "$matchlen" = "${#1}" -a \( -z "$noff" -o "$allow_noff" = '+' \) ]; then
"expr substr"? Please don't.
cf. http://www.opengroup.org/onlinepubs/000095399/utilities/expr.html
I'd probably write this part like so:
... pipe ... |
while read heads users
do
# does this rule apply to us?
head_pattern=${heads#+}
matchlen=$(expr "$1" : "$head_pattern")
test "$matchlen" = ${#1} || continue
# if non-ff, $heads must be with the '+' prefix
test -n "$noff" &&
test "z$head_pattern" = "z$heads" && continue
... Ok this is good.
^ permalink raw reply
* Re: [PATCH] cmd_reset: don't trash uncommitted changes unless told to
From: Junio C Hamano @ 2008-06-25 20:09 UTC (permalink / raw)
To: Theodore Tso
Cc: Johannes Schindelin, Johannes Sixt, Boaz Harrosh, Steven Walter,
git, jeske
In-Reply-To: <20080625195003.GB15077@mit.edu>
Theodore Tso <tytso@mit.edu> writes:
> On Wed, Jun 25, 2008 at 10:22:08AM -0700, Junio C Hamano wrote:
>> Isn't that this?
>>
>> #!/bin/sh
>> exec git checkout HEAD -- "$@"
>
> Well, I think you really want this to handle filenames with spaces:
Sorry, I do not understand that remark. Does "$@" corrupt embedded spaces
in its parameters?
^ permalink raw reply
* Re: [PATCH] cmd_reset: don't trash uncommitted changes unless told to
From: Junio C Hamano @ 2008-06-25 20:11 UTC (permalink / raw)
To: Avery Pennarun
Cc: Theodore Tso, Junio C Hamano, Johannes Schindelin, Johannes Sixt,
Boaz Harrosh, Steven Walter, git, jeske
In-Reply-To: <32541b130806251304u39c8ffdenc52904391aebd089@mail.gmail.com>
"Avery Pennarun" <apenwarr@gmail.com> writes:
> How about making "git checkout" default to HEAD if no revision is
> supplied? There's precedent for this in, say, git-diff (and I think a
> few others).
Won't fly. 'git checkout -- "$@"' is to revert to the last staged
version.
* You say "git checkout branch" when you want to "check out that branch";
* You say "git checkout -- file" when you want to "check out the file
from the index";
* You say "git checkout v1.5 -- file" when you want to "check out the
file out of that revision".
It's not that hard.
^ permalink raw reply
* Re: Where does gitweb take the owner name from?
From: Jakub Narebski @ 2008-06-25 20:12 UTC (permalink / raw)
To: Erez Zilber; +Cc: git@vger.kernel.org
In-Reply-To: <ce513bcc0806250741q3821e925uf8b6439b12062ba2@mail.gmail.com>
"Erez Zilber" <erezzi.list@gmail.com> writes:
> On the main page of gitweb (the one that lists all projects), there's
> an "Owner" column. On my gitweb, it is empty for all projects. Where
> is this information taken from?
>
> Here is how it looks on the server when I run 'ls -l':
>
> drwxr-xr-x 7 erez.zilber linux 4096 Jun 25 17:36 my_test.git
Unfortunately it is not stated explicitely neither in gitweb/README,
not gitweb/INSTALL.
Nevertheless when you grep for 'owner' in gitweb/README you can find
the following fragments:
* $projects_list
Source of projects list, either directory to scan, or text file
with list of repositories (in the "<URI-encoded repository path> SPC
<URI-encoded repository owner>" line format, [...]).
Set to $GITWEB_LIST during installation. If empty, $projectroot is
used to scan for repositories.
[...]
* gitweb.owner
You can use the gitweb.owner repository configuration variable to set
repository's owner. It is displayed in the project list and summary
page. If it's not set, filesystem directory's owner is used
(via GECOS field / real name field from getpwiud(3)).
(This might be present only in 'pu' branch, as it was part of my
patch adding support for optional 'description' field in $projects_list
file).
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: policy and mechanism for less-connected clients
From: Raimund Bauer @ 2008-06-25 20:12 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: David Jeske, Theodore Tso, git
In-Reply-To: <alpine.LNX.1.00.0806251421520.19665@iabervon.org>
On Wed, 2008-06-25 at 15:17 -0400, Daniel Barkalow wrote:
> You have a fundamental misconception about git's data model. A commit
> doesn't have a particular branch it is on. There is only the DAG, where
> each node is a commit that is structured identically to all of the other
> commits. Branches pick out particular nodes in the DAG at particular
> times.
But a branch in repository also has a local history. The ref-log.
And git could use that to produce a distributed branch-history.
<wishful thinking>
A developer prepares a series of commits in a local branch to push to
the server.
On the server the ref-log of a branch gets updated with a new entry for
each push, and other developers pulling from the server get the servers
ref-log as ref-log of their remote tracking branch and can see the
push-points there.
Those push-points seem to be somehow more important than other commits -
there was a reason for the first developer to push right this branch
tip, right?
Seems like valuable (optional) information to me.
</wishful thinking>
> It therefore doesn't make any sense to ask if a commit is directly hanging
> off of master. If your local branch is up to date, and you commit, your
> commit's parent is the current master. If you now check out master and
> merge your local branch, master gets the same (non-merge) commit.
Check if the commit is in master's ref-log?
regards,
Ray
^ permalink raw reply
* Re: [PATCH] cmd_reset: don't trash uncommitted changes unless told to
From: Avery Pennarun @ 2008-06-25 20:22 UTC (permalink / raw)
To: Junio C Hamano
Cc: Theodore Tso, Johannes Schindelin, Johannes Sixt, Boaz Harrosh,
Steven Walter, git, jeske
In-Reply-To: <7vlk0tz33n.fsf@gitster.siamese.dyndns.org>
On 6/25/08, Junio C Hamano <gitster@pobox.com> wrote:
> "Avery Pennarun" <apenwarr@gmail.com> writes:
>
> > How about making "git checkout" default to HEAD if no revision is
> > supplied? There's precedent for this in, say, git-diff (and I think a
> > few others).
>
> Won't fly. 'git checkout -- "$@"' is to revert to the last staged
> version.
Ah, I didn't catch the difference between HEAD and index there.
> * You say "git checkout -- file" when you want to "check out the file
> from the index";
The real question here is the --. Is it strictly needed? It's
optional in things like git-diff, which just do their best to guess
what you mean if you don't use the --.
If reset and checkout made the -- optional, then you could do:
git reset filename # undo an accidental "add"
git checkout filename # undo accidental modifications that haven't been added
...and save git reset --hard for people willing to take that risk.
(The fact that git-gui includes git reset --hard as a really
easy-to-click GUI command scared me the first time I saw it, too.)
I think simplifying the syntax might help to make the role of the
index less mysterious in the whole "revert" operation. It's not
obvious to me at all whether a revert-file ought to get the one from
HEAD or the one from the index. But I can easily understand and
explain checkout (copy index to working copy) and reset (undo an add).
Thanks,
Avery
^ permalink raw reply
* Re: [Bug] for-each-ref: %(object) and %(type) unimplemented
From: Mikael Magnusson @ 2008-06-25 20:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Lea Wiemann, Git Mailing List
In-Reply-To: <7v63rx1ezw.fsf@gitster.siamese.dyndns.org>
2008/6/25 Junio C Hamano <gitster@pobox.com>:
> "Mikael Magnusson" <mikachu@gmail.com> writes:
>
>> 2008/6/25 Jeff King <peff@peff.net>:
>>> On Wed, Jun 25, 2008 at 12:08:15PM -0400, Jeff King wrote:
>>>
>>>> Since you seem to be testing for-each-ref, maybe it would make sense to
>>>> put together a test script that exercises each of the atoms?
>>>
>>> Hmm. Actually, there is a test in t6300 that runs with each atom name.
>>> Unfortunately, it doesn't bother actually checking the output for
>>> sanity, so the fact that these atoms returned the empty string was
>>> missed.
>>
>> The documentation also says "tree" and "parent" should work (which they
>> also don't).
>
> The doc does not say any such thing. A tag object does not have 'parent'
> nor 'tree' header fields.
>
> Neither a commit have 'object' nor 'type' header fields and you cannot ask
> for them when showing a commit object.
Ah, sorry, I read this paragraph:
In addition to the above, for commit and tag objects,
the header field
names (tree, parent, object, type, and tag) can be used
to specify the
value in the header field.
But not this one (which perhaps should be right after the
above instead of 3 paragraphs down):
In any case, a field name that refers to a field
inapplicable to the
object referred by the ref does not cause an error. It
returns an empty
string instead.
--
Mikael Magnusson
^ permalink raw reply
* Re: [PATCH] cmd_reset: don't trash uncommitted changes unless told to
From: Steven Walter @ 2008-06-25 20:37 UTC (permalink / raw)
To: Junio C Hamano
Cc: Avery Pennarun, Theodore Tso, Johannes Schindelin, Johannes Sixt,
Boaz Harrosh, git, jeske
In-Reply-To: <7vlk0tz33n.fsf@gitster.siamese.dyndns.org>
On Wed, Jun 25, 2008 at 4:11 PM, Junio C Hamano <gitster@pobox.com> wrote:
> * You say "git checkout branch" when you want to "check out that branch";
>
> * You say "git checkout -- file" when you want to "check out the file
> from the index";
>
> * You say "git checkout v1.5 -- file" when you want to "check out the
> file out of that revision".
>
> It's not that hard.
No, it's not "that hard." But are you really claiming that it's
beyond improvement?
--
-Steven Walter <stevenrwalter@gmail.com>
^ permalink raw reply
* Re: [PATCH] cmd_reset: don't trash uncommitted changes unless told to
From: Theodore Tso @ 2008-06-25 20:38 UTC (permalink / raw)
To: Avery Pennarun
Cc: Junio C Hamano, Johannes Schindelin, Johannes Sixt, Boaz Harrosh,
Steven Walter, git, jeske
In-Reply-To: <32541b130806251304u39c8ffdenc52904391aebd089@mail.gmail.com>
On Wed, Jun 25, 2008 at 04:04:47PM -0400, Avery Pennarun wrote:
> How about making "git checkout" default to HEAD if no revision is
> supplied? There's precedent for this in, say, git-diff (and I think a
> few others).
>
> Incidentally, "checkout <filename>" was also the way to do a revert
> operation in CVS. And the way to switch branches, too, iirc. So git
> isn't being too unusual here. That said, the commands were
> deliberately renamed in svn because CVS was considered largely insane.
The one thing I would worry about is the potential ambiguity if you do
something like "git checkout FOOBAR", and FOOBAR was both a branch
name as well as a file name. How should it be interpreted? I'd argue
the real problem was we conflated two distinct operations: "switching
to a new branch", and "reverting a file" to the same name, checkout.
Hence the suggestion to add a new command, "git revert-file", where
there would be no ambiguity.
- Ted
^ permalink raw reply
* Re: policy and mechanism for less-connected clients
From: David Jeske @ 2008-06-25 19:37 UTC (permalink / raw)
To: Theodore Tso; +Cc: git
In-Reply-To: <20080625133458.GE20361@mit.edu>
Thanks for the info about shared object storage for shared repositories. That's
great, and looks like a good implementation method.
Previously I was thinking in terms of making a different server to change
behavior. However, I think the comments I've read are shifting my mindset
towards making a client-wrapper. I want to provide a system [wrapper] without
the user-burden of thinking about three repositories (local, my-public,
shared-public). Doing this as a wrapper has other benefits, like the fact that
users can treat services like repo.or.cz as the "networked filesystem of their
version control system", so I like it.
I have a model for the operations of this wrapper below.
-- Theodore Tso wrote:
> [snip] sharing in-progress work is highly overrated.
_Seeing_ unfinished changes is overrated. However, so is managing multiple
repositories and managing which data is shared.
I think my new wrapper approach below eliminates this overly-aggressive sharing
while still reducing complexity for the average user.
> So the way I would do things is to simply encourage people to do start
> their work by branching off of an up-to-date master branch, but *not*
> do any git pulls or git pushes.
You confused me here. If their repo.or.cz private repository is their only way
of sharing (because their home directory is inaccessible and emailing patches
is cumbersome), how do they exchange their own changes without pushing? Even in
a short time on git mailing list I see mini-unfinished-patches being posted.
> [ description of commit rewriting, rebase, push ]
The method you describe is burdening all users with learning a bunch of new
concepts to do things that are unnecessary micromanagement for their needs. I'd
prefer to give my users many of the benefits of DVCS/git with a
command/argument set 1/20th the size and a much simpler mental model.
Most of the software we're all using was developed while working with
centralized source control, where people just hack and commit and those commits
are not even known-working. They don't bother with patch/commit rewriting and
management, and it works out just fine. I can see how that finer granularity
may be valuable for linux kernel coordinators. However, most projects don't
need to bother with all that, and even in the ones that do, most of their
contributors don't.
Despite the success of centralized revision control, distributed source control
revision models have some very attractive features which can add efficiency to
a shared-central-repo model without straying far from the familiar (cvs up;
hack; hack; cvs up; cvs commit;) workflow. I read some commentary from Linus
that compared git to a 'filesystem', and that's what I see.. a really awesome
underlying set of mechanisms for implementing SCM.. I'm trying to understand
how to layer an easy to use SCM system on top if it.
Some 'git' users might say the right thing to do is do a different project, but
I think, just like with the filesystem-analogy, there is significant benefit to
sharing a single repository model so a simple source control system can then be
used in powerful ways by powerful users. This is similar to the direction "eg"
(easy git) is heading, but more extreme and extending to the server.
In fact, it seems like we might be better off if all of these source control
user-interfaces (cvs, perforce, git, eg, mercurial, etc. etc.) could be written
on top of a version-control-api that they shared. Witness the similar
implementation strategies of this modern rash of DVCS systems.
--------------------------------------------------------------
I'll try to explain my wrapper model in terms of an example... Imagine I'm
going to deliver a "cvs drop in replacement", ncvs, that mostly keeps the cvs
mental model, but is implemented underneath using git and just works better
than cvs (yet is simpler than git). I'll use the exact cvs command parameters
for illustration, but I wouldn't plan to do this. Notice how each ncvs command
uses many git commands. It's possible these things should be done in terms of
plumbing instead of porcelain to reduce dependence on git changes, but it's
more concise to express them as porcelain.
>From the earlier feedback, there are now two repositories, one is considered
the "shared-root" while the other is the "user" repository.
(1) make "cvs update" safe, make it easy to see granular comments for things
you have not pushed
CVS users do potentially destructive merges all the time. Despite the way we
use terminology, working files ARE a branch, and "cvs up" IS a merge. That
merge can require edits to resolve, and after those edits are complete, the
previous state is NOT recoverable. There is no reason for this. We can easily
save the delta by just making "cvs up" equal "git commit; git pull;", or
alternately, "git stash; git pull; git apply;".
: "ncvs up" ->
:
: git stash; git pull; git apply;
: git diff --stat <baseof:current branch> - un-pushed filenames
: git-show-branch <current branch> - un-pushed comments
Question: when I say "baseof:current branch", I mean "the common-ancestor
between my local-repo tracking branch and the remote-repo branch it's
tracking". How do I find that out?
Adding "git diff --stat <baseof:current branch>" helps keep us aware of what
changes are in our local repo. Any files not pushed up to the branch head on
the server are seen. Likewise with "git-show-branch <current branch>" (which
somehow is not the same as git-show-branch --current).
(2) make "planned ahead of time" branches cheap to make
"cvs up" is the easiest merge in cvs, therefore, separate sets of checked out
working files become the most common form of branching in cvs. They are
basically personal work branches that you can't commit on, and can't
collaborate on. I've seen developers with cvs working directories weeks or
months old because that's an easier way to work on different ideas than
creating a branch and checking them in. DVCS fixes this, by making branches
cheap to make, and by making all branch merges closer to the simplicity of
cvs's easy branch merge "cvs up". However, I don't need to burden the user with
the extra complexity and workload of the default being local branches, which
they then need to do more work to share. I want branches to be shared by
default.
: "ncvs tag -b --shared $branch" ->
:
: [ create a branch on the "shared root" repo, pointing
: to where I am in my local tree, if I have permission ]
: git branch --track $branch origin/$branch
: "ncvs tag -b mybranch
:
: [ create a branch on my "user" repo, pointing to where I am
in my local tree, if I have permission ]
: git branch --track $mybranch my-origin/$branch
Question: I'm not sure what commands to use above. How do I create a branch on
a remote repo when I'm on my local machine, without sshing to it?
The advantages of git's repository over cvs's repository in this use-case are
not created because the branch is on the local machine. In fact, we also
created it on the server. The benefit comes from the git revision storage model
being faster and BETTER.
Then to switch our working pointer to this branch, we might do:
: "ncvs up -r mybranch" ->
:
: git stash; git checkout mybranch; git pull;
: git stash show --relevant --recent;
Our "safe update" automatically saved away any local directory changes before
switching off to the branch (if there were any). Our "stash show" is there
always to show us if any stashes hang off a recent parent of the tree we just
switched to, but it only shows them if they are hanging off this tree, and only
if they are recent. If there is, we might want to look at or grab it, or we
might just ignore it and not care.
(3) allow users to commit their 'final' changes to others (only on the branch
they are on)
: "ncvs commit" -> "git commit; git push <only this branch>;"
Question: how do I only push the branch I'm on? "eg" says it does this, but
from a quick look at the code, it wasn't obvious to me how.
Developers who are plenty happy with their existing model of never saving local
changes, can continue doing what they are doing. This makes the ability to save
local changes an added benefit to the users like me that want to do it, instead
of an extra burden to the other users. It also simplifies the issue of which
changes are pushed to the server and which are not, because pushing is managed
by "git push <only this branch>", not by creating and managing local and remote
branch names separately. (easy git took the same approach with push)
(4) Allow users to save interim changes, without ahead of time planning, ahead
of time nameing, and hopefully, without naming at all.
Saving interim changes in a cvs working tree before merging with head is not
cheap. Making my own branch tag isn't too hard, but it takes a long time on a
big tree. Ironically, perforce made branching mechanism faster while making the
cognitive load of branch hing much higher.
: "ncvs save" -> "git commit -a"
:
: "ncvs stash [$name]" ->
:
: $currentbranch = `git branch`
: $base-ish = '<baseof: current branch>'
: git stash;
: git branch -m $currentbranch $name;
: git checkout $baseish;
: git branch $currentbranch
This "ncvs stash" is acknowledging the value of the "git stash" idea, while
also recognizing that when I'm using "git commit" regularly, I don't have
anything in the working set! I really want to stash the changes made since
"origin/<branchname>" and return there with my local <branchname>. This is
really after the fact branch creation. If no $name is supplied, then it can
auto-generate one like stash does.
(5) make it obvious there is a difference between local and remote changes, but
make it easy to diff against remote before "ncvs commit;"
: "ncvs diff" ->
:
: echo -n "since commit(-C): " \
: `git diff --shortstat <baseof:current branch>`; \
: echo
: echo -n "since save(-S): " \
: `git diff`; echo
:
: "ncvs diff -S" -> "git diff"
: "ncvs diff -C" -> "git diff <baseof:current branch>
--------------------------------------------------------------
I'm primarily trying to understand how to map my model to git.
Continued thanks for the discussion and help.
^ permalink raw reply
* Re: policy and mechanism for less-connected clients
From: David Jeske @ 2008-06-25 19:37 UTC (permalink / raw)
To: Theodore Tso; +Cc: git
In-Reply-To: <20080625133458.GE20361@mit.edu>
Thanks for the info about shared object storage for shared repositories. That's
great, and looks like a good implementation method.
Previously I was thinking in terms of making a different server to change
behavior. However, I think the comments I've read are shifting my mindset
towards making a client-wrapper. I want to provide a system [wrapper] without
the user-burden of thinking about three repositories (local, my-public,
shared-public). Doing this as a wrapper has other benefits, like the fact that
users can treat services like repo.or.cz as the "networked filesystem of their
version control system", so I like it.
I have a model for the operations of this wrapper below.
-- Theodore Tso wrote:
> [snip] sharing in-progress work is highly overrated.
_Seeing_ unfinished changes is overrated. However, so is managing multiple
repositories and managing which data is shared.
I think my new wrapper approach below eliminates this overly-aggressive sharing
while still reducing complexity for the average user.
> So the way I would do things is to simply encourage people to do start
> their work by branching off of an up-to-date master branch, but *not*
> do any git pulls or git pushes.
You confused me here. If their repo.or.cz private repository is their only way
of sharing (because their home directory is inaccessible and emailing patches
is cumbersome), how do they exchange their own changes without pushing? Even in
a short time on git mailing list I see mini-unfinished-patches being posted.
> [ description of commit rewriting, rebase, push ]
The method you describe is burdening all users with learning a bunch of new
concepts to do things that are unnecessary micromanagement for their needs. I'd
prefer to give my users many of the benefits of DVCS/git with a
command/argument set 1/20th the size and a much simpler mental model.
Most of the software we're all using was developed while working with
centralized source control, where people just hack and commit and those commits
are not even known-working. They don't bother with patch/commit rewriting and
management, and it works out just fine. I can see how that finer granularity
may be valuable for linux kernel coordinators. However, most projects don't
need to bother with all that, and even in the ones that do, most of their
contributors don't.
Despite the success of centralized revision control, distributed source control
revision models have some very attractive features which can add efficiency to
a shared-central-repo model without straying far from the familiar (cvs up;
hack; hack; cvs up; cvs commit;) workflow. I read some commentary from Linus
that compared git to a 'filesystem', and that's what I see.. a really awesome
underlying set of mechanisms for implementing SCM.. I'm trying to understand
how to layer an easy to use SCM system on top if it.
Some 'git' users might say the right thing to do is do a different project, but
I think, just like with the filesystem-analogy, there is significant benefit to
sharing a single repository model so a simple source control system can then be
used in powerful ways by powerful users. This is similar to the direction "eg"
(easy git) is heading, but more extreme and extending to the server.
In fact, it seems like we might be better off if all of these source control
user-interfaces (cvs, perforce, git, eg, mercurial, etc. etc.) could be written
on top of a version-control-api that they shared. Witness the similar
implementation strategies of this modern rash of DVCS systems.
--------------------------------------------------------------
I'll try to explain my wrapper model in terms of an example... Imagine I'm
going to deliver a "cvs drop in replacement", ncvs, that mostly keeps the cvs
mental model, but is implemented underneath using git and just works better
than cvs (yet is simpler than git). I'll use the exact cvs command parameters
for illustration, but I wouldn't plan to do this. Notice how each ncvs command
uses many git commands. It's possible these things should be done in terms of
plumbing instead of porcelain to reduce dependence on git changes, but it's
more concise to express them as porcelain.
>From the earlier feedback, there are now two repositories, one is considered
the "shared-root" while the other is the "user" repository.
(1) make "cvs update" safe, make it easy to see granular comments for things
you have not pushed
CVS users do potentially destructive merges all the time. Despite the way we
use terminology, working files ARE a branch, and "cvs up" IS a merge. That
merge can require edits to resolve, and after those edits are complete, the
previous state is NOT recoverable. There is no reason for this. We can easily
save the delta by just making "cvs up" equal "git commit; git pull;", or
alternately, "git stash; git pull; git apply;".
: "ncvs up" ->
:
: git stash; git pull; git apply;
: git diff --stat <baseof:current branch> - un-pushed filenames
: git-show-branch <current branch> - un-pushed comments
Question: when I say "baseof:current branch", I mean "the common-ancestor
between my local-repo tracking branch and the remote-repo branch it's
tracking". How do I find that out?
Adding "git diff --stat <baseof:current branch>" helps keep us aware of what
changes are in our local repo. Any files not pushed up to the branch head on
the server are seen. Likewise with "git-show-branch <current branch>" (which
somehow is not the same as git-show-branch --current).
(2) make "planned ahead of time" branches cheap to make
"cvs up" is the easiest merge in cvs, therefore, separate sets of checked out
working files become the most common form of branching in cvs. They are
basically personal work branches that you can't commit on, and can't
collaborate on. I've seen developers with cvs working directories weeks or
months old because that's an easier way to work on different ideas than
creating a branch and checking them in. DVCS fixes this, by making branches
cheap to make, and by making all branch merges closer to the simplicity of
cvs's easy branch merge "cvs up". However, I don't need to burden the user with
the extra complexity and workload of the default being local branches, which
they then need to do more work to share. I want branches to be shared by
default.
: "ncvs tag -b --shared $branch" ->
:
: [ create a branch on the "shared root" repo, pointing
: to where I am in my local tree, if I have permission ]
: git branch --track $branch origin/$branch
: "ncvs tag -b mybranch
:
: [ create a branch on my "user" repo, pointing to where I am
in my local tree, if I have permission ]
: git branch --track $mybranch my-origin/$branch
Question: I'm not sure what commands to use above. How do I create a branch on
a remote repo when I'm on my local machine, without sshing to it?
The advantages of git's repository over cvs's repository in this use-case are
not created because the branch is on the local machine. In fact, we also
created it on the server. The benefit comes from the git revision storage model
being faster and BETTER.
Then to switch our working pointer to this branch, we might do:
: "ncvs up -r mybranch" ->
:
: git stash; git checkout mybranch; git pull;
: git stash show --relevant --recent;
Our "safe update" automatically saved away any local directory changes before
switching off to the branch (if there were any). Our "stash show" is there
always to show us if any stashes hang off a recent parent of the tree we just
switched to, but it only shows them if they are hanging off this tree, and only
if they are recent. If there is, we might want to look at or grab it, or we
might just ignore it and not care.
(3) allow users to commit their 'final' changes to others (only on the branch
they are on)
: "ncvs commit" -> "git commit; git push <only this branch>;"
Question: how do I only push the branch I'm on? "eg" says it does this, but
from a quick look at the code, it wasn't obvious to me how.
Developers who are plenty happy with their existing model of never saving local
changes, can continue doing what they are doing. This makes the ability to save
local changes an added benefit to the users like me that want to do it, instead
of an extra burden to the other users. It also simplifies the issue of which
changes are pushed to the server and which are not, because pushing is managed
by "git push <only this branch>", not by creating and managing local and remote
branch names separately. (easy git took the same approach with push)
(4) Allow users to save interim changes, without ahead of time planning, ahead
of time nameing, and hopefully, without naming at all.
Saving interim changes in a cvs working tree before merging with head is not
cheap. Making my own branch tag isn't too hard, but it takes a long time on a
big tree. Ironically, perforce made branching mechanism faster while making the
cognitive load of branch hing much higher.
: "ncvs save" -> "git commit -a"
:
: "ncvs stash [$name]" ->
:
: $currentbranch = `git branch`
: $base-ish = '<baseof: current branch>'
: git stash;
: git branch -m $currentbranch $name;
: git checkout $baseish;
: git branch $currentbranch
This "ncvs stash" is acknowledging the value of the "git stash" idea, while
also recognizing that when I'm using "git commit" regularly, I don't have
anything in the working set! I really want to stash the changes made since
"origin/<branchname>" and return there with my local <branchname>. This is
really after the fact branch creation. If no $name is supplied, then it can
auto-generate one like stash does.
(5) make it obvious there is a difference between local and remote changes, but
make it easy to diff against remote before "ncvs commit;"
: "ncvs diff" ->
:
: echo -n "since commit(-C): " \
: `git diff --shortstat <baseof:current branch>`; \
: echo
: echo -n "since save(-S): " \
: `git diff`; echo
:
: "ncvs diff -S" -> "git diff"
: "ncvs diff -C" -> "git diff <baseof:current branch>
--------------------------------------------------------------
I'm primarily trying to understand how to map my model to git.
Continued thanks for the discussion and help.
^ permalink raw reply
* Re: [PATCH] cmd_reset: don't trash uncommitted changes unless told to
From: Junio C Hamano @ 2008-06-25 20:48 UTC (permalink / raw)
To: Avery Pennarun
Cc: Junio C Hamano, Theodore Tso, Johannes Schindelin, Johannes Sixt,
Boaz Harrosh, Steven Walter, git, jeske
In-Reply-To: <32541b130806251322l478faa87gc9f2016254689022@mail.gmail.com>
"Avery Pennarun" <apenwarr@gmail.com> writes:
>> * You say "git checkout -- file" when you want to "check out the file
>> from the index";
>
> The real question here is the --. Is it strictly needed? It's
> optional in things like git-diff, which just do their best to guess
> what you mean if you don't use the --.
No, I wrote -- only for clarity, because you can happen to have a branch
whose name is the same as the file. Otherwise you can safely omit it,
just like git-diff and any other commands that follow the -- convention.
I have a work tree that has an untracked file HEAD and master just to
catch script breakages that forgets to place -- in appropriate places when
they deal with user supplied pathnames.
^ permalink raw reply
* Re: how to rewalk the commit list after rename detection
From: Jakub Narebski @ 2008-06-25 20:50 UTC (permalink / raw)
To: Alex Riesen; +Cc: Don Zickus, git
In-Reply-To: <20080625190404.GE4039@steel.home>
Alex Riesen <raa.lkml@gmail.com> writes:
> Don Zickus, Mon, Jun 23, 2008 17:38:14 +0200:
> >
> > I am trying to find a way to handle a situation where I am looking for a
> > change in a particular file, but the filename is old and has since been
> > renamed.
> >
> > Processing the commit list internally (using init_revisions,
> > setup_revisions, get_revision), I can easily find the rename of the file,
> > but that is usually the start of the walk for that file (as it was just
> > deleted for the rename). I do not know how to re-walk the commits list
> > armed with the new file name.
>
> Try looking at git log --follow <name>
Unfortunately it _almost_ works, see:
"git log --follow <filename> doesn't follow across 'subtree strategy' merge"
Message-ID: <200806221451.50624.jnareb@gmail.com>
http://permalink.gmane.org/gmane.comp.version-control.git/85766
("git log --follow gitweb/gitweb.perl follows rename from gitweb/gitweb.cgi,
but not rename (moving) from gitweb.cgi in a merge commit).
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] cmd_reset: don't trash uncommitted changes unless told to
From: Junio C Hamano @ 2008-06-25 20:50 UTC (permalink / raw)
To: Theodore Tso
Cc: Avery Pennarun, Johannes Schindelin, Johannes Sixt, Boaz Harrosh,
Steven Walter, git, jeske
In-Reply-To: <20080625203822.GA7827@mit.edu>
Theodore Tso <tytso@mit.edu> writes:
> The one thing I would worry about is the potential ambiguity if you do
> something like "git checkout FOOBAR", and FOOBAR was both a branch
> name as well as a file name. How should it be interpreted? I'd argue
> the real problem was we conflated two distinct operations: "switching
> to a new branch", and "reverting a file" to the same name, checkout.
I just replied to Avery about that. -- is always the way to disambiguate
between refs (that come before --) and paths (that come after --), not
limited to "git checkout" but with other commands such as "git log", "git
diff", etc.
^ permalink raw reply
* Re: policy and mechanism for less-connected clients
From: Jakub Narebski @ 2008-06-25 20:52 UTC (permalink / raw)
To: git
In-Reply-To: <43260.7826347978$1214426654@news.gmane.org>
<opublikowany i wysłany>
David Jeske wrote:
> Question: when I say "baseof:current branch", I mean "the common-ancestor
> between my local-repo tracking branch and the remote-repo branch it's
> tracking". How do I find that out?
git-merge-base
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: policy and mechanism for less-connected clients
From: Jakub Narebski @ 2008-06-25 20:54 UTC (permalink / raw)
To: git
In-Reply-To: <43260.7826347978$1214426654@news.gmane.org>
David Jeske wrote:
> Question: how do I only push the branch I'm on? "eg" says it does this, but
> from a quick look at the code, it wasn't obvious to me how.
git push <remote> HEAD # with current enough git
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] git-gui: Don't select the wrong file if the last listed file is staged.
From: Shawn O. Pearce @ 2008-06-25 20:57 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Abhijit Menon-Sen, git
In-Reply-To: <486222A6.70205@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> wrote:
> Abhijit Menon-Sen schrieb:
> > Johannes Sixt noticed that if the last file in the list was staged, my
> > earlier patch would display the diff for the penultimate file, but show
> > the file _before_ that as being selected.
> >
> > This was due to my misunderstanding the lno argument to show_diff.
> >
> > This patch fixes the problem: lno is not decremented in the special case
> > to handle the last item in the list (though we still need to use $lno-1
> > to find the right path for the next diff).
>
> Thanks. It works here, too:
Thanks, both. Its in my tree.
--
Shawn.
^ 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