* Re: [PATCH] Document git-stash
From: Junio C Hamano @ 2007-07-01 6:48 UTC (permalink / raw)
To: しらいしななこ
Cc: GIT, Johannes Schindelin
In-Reply-To: <200707010533.l615XiH6006728@mi1.bluebottle.com>
Thanks.
^ permalink raw reply
* Re: Making binary diffs
From: Shawn O. Pearce @ 2007-07-01 6:17 UTC (permalink / raw)
To: Geoff Russell; +Cc: git
In-Reply-To: <93c3eada0706302314m20616a17s762704606c881278@mail.gmail.com>
Geoff Russell <geoffrey.russell@gmail.com> wrote:
> "git format-patch" generates binary diffs for binary files (e.g pdfs)
> in its patches,
> but "git diff -p" just tells me that a binary file is different and doesn't
> generate the actual diff.
--binary::
In addition to --full-index, output "binary diff" that
can be applied with "git apply".
Should work with all of the "diff things" like `git diff`,
`git log`, etc. See the diff-options.txt in Documentation.
--
Shawn.
^ permalink raw reply
* Making binary diffs
From: Geoff Russell @ 2007-07-01 6:14 UTC (permalink / raw)
To: git
Hi,
"git format-patch" generates binary diffs for binary files (e.g pdfs)
in its patches,
but "git diff -p" just tells me that a binary file is different and doesn't
generate the actual diff.
Is there some switch I'm missing to tell "git diff" to generate a
binary diff on binary files?
Cheers,
Geoff Russell
^ permalink raw reply
* Re: Non-http dumb protocols
From: Julian Phillips @ 2007-07-01 5:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Daniel Barkalow, git
In-Reply-To: <7vbqewakz8.fsf@assigned-by-dhcp.cox.net>
On Sat, 30 Jun 2007, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
>> Do we actually support local-fetch and ssh-fetch/ssh-push any more? They
>> seem to me to have been entirely supplanted with respect to functionality
>> for a long time now, but the programs are still there. This complicates
>> http-fetch, because only one -fetch can be linked into a binary as
>> currently designed, and we may want to make http-fetch builtin at some
>> point. Can we remove the other dumb protocols and merge fetch.c into
>> http-fetch.c?
> To be linked with the rest of git, I think the global symbols
> fetch.c has are named a little too generically, and they would
> need to be fixed first. It may make sense to do the "backend
> descriptor" code restructure first _before_ linking anything
> with the rest of git. We can rename main() in *-fetch.c to
> cmd_*_fetch() only for the ones that we choose to make built-in
> when the conversion is ready.
>
> Having said that, I have a feeling that many people do not build
> any of the commit walkers, and especially the http walker,
> because they have no need for dumb protocols, and libcurl-dev is
> just another piece of dependency they do not have to have. If
> we were to do a built-in http-fetch, we also need to make sure
> it is done in such a way that people can choose to configure it
> out.
As part of making fetch a builtin, I also made http-fetch a builtin so
that I reuse some of the code. When I did this it kept the same optional
build status as the original separate program. Since Daniel based his
work on mine, he should have this change too ... however I didn't do any
renaming of symbols in builtin-http-fetch.c other than the minimum
necessary to make it a builtin.
--
Julian
---
Taxes are going up so fast, the government is likely to price itself
out of the market.
^ permalink raw reply
* [PATCH] Document git-stash
From: しらいしななこ @ 2007-07-01 5:26 UTC (permalink / raw)
To: GIT; +Cc: Johannes Schindelin, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0706301853400.4438@racer.site>
This describes the git-stash command.
I borrowed a few paragraphs from Johannes's version, and added a few
examples.
Signed-off-by: Nanako Shiraishi <nanako3@bluebottle.com>
---
Documentation/cmd-list.perl | 1 +
Documentation/git-stash.txt | 162 +++++++++++++++++++++++++++++++++++++++++++
2 files changed, 163 insertions(+), 0 deletions(-)
create mode 100644 Documentation/git-stash.txt
diff --git a/Documentation/cmd-list.perl b/Documentation/cmd-list.perl
index fcea1d7..8ee8122 100755
--- a/Documentation/cmd-list.perl
+++ b/Documentation/cmd-list.perl
@@ -178,6 +178,7 @@ git-show-ref plumbinginterrogators
git-sh-setup purehelpers
git-ssh-fetch synchingrepositories
git-ssh-upload synchingrepositories
+git-stash mainporcelain
git-status mainporcelain
git-stripspace purehelpers
git-submodule mainporcelain
diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
new file mode 100644
index 0000000..17ebc83
--- /dev/null
+++ b/Documentation/git-stash.txt
@@ -0,0 +1,162 @@
+git-stash(1)
+============
+
+NAME
+----
+git-stash - Stash the changes in a dirty working directory away
+
+SYNOPSIS
+--------
+[verse]
+'git-stash'
+'git-stash' [list | show [<stash>] | apply [<stash>] | clear]
+
+DESCRIPTION
+-----------
+
+Use 'git-stash' when you want to record the current state of the
+working directory and the index, but want to go back to a clean
+working directory. The command saves your local modifications away
+and reverts the working directory to match the `HEAD` commit.
+
+The modifications stashed away by this command can be listed with
+`git-stash list`, inspected with `git-stash show`, and restored
+(potentially on top of a different commit) with `git-stash apply`
+commands. The default operation when called without options is to
+save the changes away.
+
+The latest stash you created is stored in `$GIT_DIR/refs/stash`; older
+stashes are found in the reflog of this refererence and can be named using
+the usual reflog syntax (e.g. `stash@{1}` is the stash one previously made,
+`stash@{2}` is the one before it, `stash@{2.hours.ago}` is also possible).
+
+OPTIONS
+-------
+
+(no subcommand)::
+
+ Save your local modifications to a new 'stash', and run `git-reset
+ --hard` to revert them.
+
+list::
+
+ List the stashes that you currently have. Each 'stash' is listed
+ with its name (e.g. `stash@{0}` is the latest stash, `stash@{1} is
+ the one before), the name of the branch that was current when the
+ stash was made, and a short description of the commit the stash was
+ based on.
++
+----------------------------------------------------------------
+stash@{0}: submit: 6ebd0e2... Add git-stash
+stash@{1}: master: 9cc0589... Merge branch 'master' of gfi
+----------------------------------------------------------------
+
+show [<stash>]::
+
+ Show the changes recorded in the stash. When no `<stash>` is given,
+ shows the latest one. By default, the command shows diffstat, but
+ you can add `-p` option (i.e. `git stash show -p stash@{2}`) to view
+ it in patch form.
+
+apply [<stash>]::
+
+ Restores the changes recorded in the stash on top of the current
+ working tree state. When no `<stash>` is given, applies the latest
+ one. The working directory must match the index. When the changes
+ conflict, you need to resolve them by hand and mark the result with
+ `git add` as usual. When the changes are cleanly merged, your
+ earlier local changes stored in the stash becomes the differences
+ between the index and the working tree (i.e. `git diff`), except
+ that newly created files are registered in the index (i.e. `git diff
+ --cached` is necessary to review the newly added files).
+
+clear::
+ Removes all the stashed states.
+
+
+DISCUSSION
+----------
+
+A stash is represented as a commit whose tree records the state of the
+working directory, and its first parent is the commit at `HEAD` when
+the stash was created. The tree of the second parent records the
+state of the index when the stash is made, and it is made a child of
+the `HEAD` commit. The ancestry graph looks like this:
+
+ .----W
+ / /
+ ...--H----I
+
+where `H` is the `HEAD` commit, `I` is a commit that records the state
+of the index, and `W` is a commit that records the state of the working
+tree.
+
+
+EXAMPLES
+--------
+
+Pulling into a dirty tree::
+
+When you are in the middle of something, you learn that there are
+changes that possibly are relevant to what you are doing in the
+upstream. When your local changes do not conflict with the changes in
+the upstream, a simple `git pull` will let you move forward.
++
+However, there are cases in which your local changes do conflict with
+the upstream changes, and `git pull` refuses to overwrite your
+changes. In such a case, you can first stash your changes away,
+perform a pull, and then unstash, like this:
++
+----------------------------------------------------------------
+$ git pull
+...
+file foobar not up to date, cannot merge.
+$ git stash
+$ git pull
+$ git stash apply
+----------------------------------------------------------------
+
+Interrupted workflow::
+
+When you are in the middle of something, your boss comes in and
+demands you to fix something immediately. Traditionally, you would
+make a commit to a temporary branch to store your changes away, and
+come back to make the emergency fix, like this:
++
+----------------------------------------------------------------
+... hack hack hack ...
+$ git checkout -b my_wip
+$ git commit -a -m "WIP"
+$ git checkout master
+$ edit emergency fix
+$ git commit -a -m "Fix in a hurry"
+$ git checkout my_wip
+$ git reset --soft HEAD^
+... continue hacking ...
+----------------------------------------------------------------
++
+You can use `git-stash` to simplify the above, like this:
++
+----------------------------------------------------------------
+... hack hack hack ...
+$ git stash
+$ edit emergency fix
+$ git commit -a -m "Fix in a hurry"
+$ git stash apply
+... continue hacking ...
+----------------------------------------------------------------
+
+SEE ALSO
+--------
+gitlink:git-checkout[1],
+gitlink:git-commit[1],
+gitlink:git-reflog[1],
+gitlink:git-reset[1]
+
+AUTHOR
+------
+Written by Nanako Shiraishi <nanako3@bluebottle.com>
+
+GIT
+---
+Part of the gitlink:git[7] suite
--
1.5.2.2
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
----------------------------------------------------------------------
Get a free email account with anti spam protection.
http://www.bluebottle.com
^ permalink raw reply related
* Re: [PATCH] git-svn: cache max revision in rev_db databases
From: Eric Wong @ 2007-07-01 5:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Sam Vilain
In-Reply-To: <7vfy48940k.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> wrote:
> Sam Vilain <sam.vilain@catalyst.net.nz> writes:
>
> > Cache the maximum revision for each rev_db URL rather than looking it
> > up each time. This saves a lot of time when rebuilding indexes on a
> > freshly cloned repository.
> >
> > Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz>
>
> I think both the previous one from Sam that makes it use git-log
> instead of git-rev-list and this one looks sane. Ack/Nack is
> appreciated.
Now that 80583c0ef61cc966c7eee79cf3623a83197e19b8 is in, both patches
are:
Acked-by: Eric Wong <normalperson@yhbt.net>
> > ---
> > git-svn.perl | 4 ++++
> > 1 files changed, 4 insertions(+), 0 deletions(-)
> >
> > diff --git a/git-svn.perl b/git-svn.perl
> > index 556cd7d..a8b6669 100755
> > --- a/git-svn.perl
> > +++ b/git-svn.perl
> > @@ -801,6 +801,7 @@ sub working_head_info {
> > my ($head, $refs) = @_;
> > my ($fh, $ctx) = command_output_pipe('log', $head);
> > my $hash;
> > + my %max;
> > while (<$fh>) {
> > if ( m{^commit ($::sha1)$} ) {
> > unshift @$refs, $hash if $hash and $refs;
> > @@ -810,11 +811,14 @@ sub working_head_info {
> > next unless s{^\s*(git-svn-id:)}{$1};
> > my ($url, $rev, $uuid) = extract_metadata($_);
> > if (defined $url && defined $rev) {
> > + next if $max{$url} and $max{$url} < $rev;
> > if (my $gs = Git::SVN->find_by_url($url)) {
> > my $c = $gs->rev_db_get($rev);
> > if ($c && $c eq $hash) {
> > close $fh; # break the pipe
> > return ($url, $rev, $uuid, $gs);
> > + } else {
> > + $max{$url} ||= $gs->rev_db_max;
> > }
> > }
> > }
> > --
> > 1.5.2.1.1131.g3b90
>
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] Add a manual page for git-stash
From: Junio C Hamano @ 2007-07-01 5:20 UTC (permalink / raw)
To: Johannes Schindelin
Cc: しらいしななこ, GIT
In-Reply-To: <Pine.LNX.4.64.0706301644190.4438@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
> Documentation/git-stash.txt | 116 +++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 116 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/git-stash.txt
By the way, whoever does the documentation needs to list it in
the command list (Documentation/cmd-list.perl).
^ permalink raw reply
* Re: [PATCH] git-svn: cache max revision in rev_db databases
From: Junio C Hamano @ 2007-07-01 3:50 UTC (permalink / raw)
To: Eric Wong; +Cc: git, Sam Vilain
In-Reply-To: <11831937823184-git-send-email-sam.vilain@catalyst.net.nz>
Sam Vilain <sam.vilain@catalyst.net.nz> writes:
> Cache the maximum revision for each rev_db URL rather than looking it
> up each time. This saves a lot of time when rebuilding indexes on a
> freshly cloned repository.
>
> Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz>
I think both the previous one from Sam that makes it use git-log
instead of git-rev-list and this one looks sane. Ack/Nack is
appreciated.
> ---
> git-svn.perl | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/git-svn.perl b/git-svn.perl
> index 556cd7d..a8b6669 100755
> --- a/git-svn.perl
> +++ b/git-svn.perl
> @@ -801,6 +801,7 @@ sub working_head_info {
> my ($head, $refs) = @_;
> my ($fh, $ctx) = command_output_pipe('log', $head);
> my $hash;
> + my %max;
> while (<$fh>) {
> if ( m{^commit ($::sha1)$} ) {
> unshift @$refs, $hash if $hash and $refs;
> @@ -810,11 +811,14 @@ sub working_head_info {
> next unless s{^\s*(git-svn-id:)}{$1};
> my ($url, $rev, $uuid) = extract_metadata($_);
> if (defined $url && defined $rev) {
> + next if $max{$url} and $max{$url} < $rev;
> if (my $gs = Git::SVN->find_by_url($url)) {
> my $c = $gs->rev_db_get($rev);
> if ($c && $c eq $hash) {
> close $fh; # break the pipe
> return ($url, $rev, $uuid, $gs);
> + } else {
> + $max{$url} ||= $gs->rev_db_max;
> }
> }
> }
> --
> 1.5.2.1.1131.g3b90
^ permalink raw reply
* Re: Start deprecating "git-command" in favor of "git command"
From: Junio C Hamano @ 2007-07-01 3:32 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Yann Dirson, Git Mailing List
In-Reply-To: <alpine.LFD.0.98.0706301955560.1172@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Sat, 30 Jun 2007, Junio C Hamano wrote:
>>
>> The current scripts that largely use "git-foo" do not have to be
>> changed. Your --no-alias and Linus's "git - foo" would be a
>> "solution", but both require changes to the scripts
>
> No. I didn't (and wouldn't) _remove_ the "git-xyzzy" thing.
>
> I'm just saying that it should be considered a secondary thing, and we
> should have the long-term *option* to remove it.
>
> And in order to do that, we should start removing our dependency on it
> earlier rather than later.
>
> Your whole alias argument is bogus, since we don't _allow_ aliases to
> override the command (as you yourself did admit).
>
> So changing the current scripts from using "git-xyzzy" to using "git
> xyzzy" changes nothing at all - except it gives people the _option_ to
> stop installing the git-* links if they don't want to.
People who do not want to have git-xyzzy in their PATH had that
choice for eternity ("make gitexecdir=$(prefix)/libexec/git");
your patch is not needed to satisfy that.
What it buys us is that they do not have to have
$(prefix)/libexec/git/git-xyzzy for all xyzzy that git.c knows
about as built-ins (obviously non built-ins are still needed).
I do see value in not cluttering $(prefix)/bin/ quite a lot, but
does it matter if we have 140 links or 70 links (the differences
are 70 or so built-ins we currently have) in $(prefix)/libexec/git?
I would not be objecting to it if this was about $(bindir).
> With my patch, it's a _choice_, rather than a straight-jacket.
But that is a different choice. Choice of having only 70
git-xyzzy in $(gitexecdir) vs having to have 140 (among which 70
are hardlinks).
Your patch _closes the door_ for us to implement overriding
aliases later if we wanted to; we would need to go back to the
scripts and say "git --no-alias xyzzy" again.
^ permalink raw reply
* [PATCH] t7004: ship trustdb to avoid gpg warnings
From: Junio C Hamano @ 2007-07-01 3:14 UTC (permalink / raw)
To: Carlos Rica; +Cc: Johannes Schindelin, git
In-Reply-To: <Pine.LNX.4.64.0706301956240.4438@racer.site>
This avoids warning messages from gpg while verifying the tags; without it,
the program complains that the key is not certified with a trusted signature.
---
t/t7004/trustdb.gpg | Bin 0 -> 1280 bytes
1 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 t/t7004/trustdb.gpg
diff --git a/t/t7004/trustdb.gpg b/t/t7004/trustdb.gpg
new file mode 100644
index 0000000000000000000000000000000000000000..abace962b8bf84be688a6f27e4ebd0ee7052f210
GIT binary patch
literal 1280
zcmZQfFGy!*W@Ke#U|?`dKkWykumMIcY@%4iM%7^n6rj+M4;MLzzlOX&pwTnxkD-}P
zc^HbXN0fL!SIq1?>env3?W^3`d(OOU5YNaX{KU(k^<0;M@87ONv)_6ZxD={-=<kYO
M2Ud3=2BC}r0AuhNr2qf`
literal 0
HcmV?d00001
--
1.5.2
^ permalink raw reply
* Re: Start deprecating "git-command" in favor of "git command"
From: Linus Torvalds @ 2007-07-01 3:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Yann Dirson, Git Mailing List
In-Reply-To: <7vtzsoami9.fsf@assigned-by-dhcp.cox.net>
On Sat, 30 Jun 2007, Junio C Hamano wrote:
>
> The current scripts that largely use "git-foo" do not have to be
> changed. Your --no-alias and Linus's "git - foo" would be a
> "solution", but both require changes to the scripts
No. I didn't (and wouldn't) _remove_ the "git-xyzzy" thing.
I'm just saying that it should be considered a secondary thing, and we
should have the long-term *option* to remove it.
And in order to do that, we should start removing our dependency on it
earlier rather than later.
Your whole alias argument is bogus, since we don't _allow_ aliases to
override the command (as you yourself did admit).
So changing the current scripts from using "git-xyzzy" to using "git
xyzzy" changes nothing at all - except it gives people the _option_ to
stop installing the git-* links if they don't want to.
With my script, you can actually do it and have a mostly working setup.
Yeah, not installing the git-* links will actually break some things, but
it won't break the really common stuff.
As it is, we have to have the git-* links somewhere, and I don't see why
you or others argue that that _requirement_ is somehow a better thing than
not requiring it.
With my patch, it's a _choice_, rather than a straight-jacket.
Linus
^ permalink raw reply
* Re: Start deprecating "git-command" in favor of "git command"
From: Theodore Tso @ 2007-07-01 3:00 UTC (permalink / raw)
To: eschvoca; +Cc: git
In-Reply-To: <2b05065b0706301848o21cf9e90g14f759a99196dcf2@mail.gmail.com>
On Sat, Jun 30, 2007 at 09:48:26PM -0400, eschvoca wrote:
> By removing the dash I would miss out on man pages too.
The man pages are something that needs careful consideration. Some
man programs use the PATH as a hint to figure out which man page to
show --- i.e., if /usr/local/bin/git-log is in the path then it's
likely that the man page you want to show is the one in
/usr/local/man/man1/git-log.1.
If we don't install git-log in the PATH, for some setups people won't
be able to see the man page for git-log.
- Ted
^ permalink raw reply
* Re: Non-http dumb protocols
From: Junio C Hamano @ 2007-07-01 2:58 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0706301613410.14638@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> Do we actually support local-fetch and ssh-fetch/ssh-push any more? They
> seem to me to have been entirely supplanted with respect to functionality
> for a long time now, but the programs are still there. This complicates
> http-fetch, because only one -fetch can be linked into a binary as
> currently designed, and we may want to make http-fetch builtin at some
> point. Can we remove the other dumb protocols and merge fetch.c into
> http-fetch.c?
I have a feeling that nobody uses commit walkers other than
http. I do not see a point in ssh-fetch/push (we said it is
deprecated long time ago, and I was just too lazy to propose and
actually remove it when I did 1.5.2). local-fetch _might_ be
useful as a debugging tool when you have trouble not related to
libcurl in http-fetch, but other than that I do not see a point
to it either.
I am personally Ok with removing them on the sole basis of "they
are practically disused"; but there may be people on the list
with different opinions (at least here, they are not stupid nor
ugly).
However, from "technical" point of view, I do not think the
commit walker framework "fetch.c" is beyond salvaging, as you
make it sound, to make it a built-in. The commit walker
framework was your work IIRC, so this may be preaching to the
choir, but my understanding is that it wants the following
functions defined in the transport backend module:
extern int fetch(unsigned char *sha1);
extern void prefetch(unsigned char *sha1);
extern int fetch_ref(char *ref, unsigned char *sha1);
and exports the following symbols to be set:
extern int get_tree;
extern int get_history;
extern int get_all;
extern int get_verbosely;
extern int get_recover;
I think you could define
struct fetch_backend {
int (*fetch_fn)(const unsigned char *);
void (*prefetch_fn)(const unsigned char *);
int (*fetch_ref_fn)(const char *, const unsigned char *);
int get_tree;
int get_history;
int get_all;
int get_verbosely;
int get_recover;
};
and have the backend "main()" pass a pointer to it to functions
pull(), pull_targets_stdin() and such, that are defined in
fetch.c. That way, you can have multiple backend linked in.
To be linked with the rest of git, I think the global symbols
fetch.c has are named a little too generically, and they would
need to be fixed first. It may make sense to do the "backend
descriptor" code restructure first _before_ linking anything
with the rest of git. We can rename main() in *-fetch.c to
cmd_*_fetch() only for the ones that we choose to make built-in
when the conversion is ready.
Having said that, I have a feeling that many people do not build
any of the commit walkers, and especially the http walker,
because they have no need for dumb protocols, and libcurl-dev is
just another piece of dependency they do not have to have. If
we were to do a built-in http-fetch, we also need to make sure
it is done in such a way that people can choose to configure it
out.
^ permalink raw reply
* Re: Start deprecating "git-command" in favor of "git command"
From: Junio C Hamano @ 2007-07-01 2:25 UTC (permalink / raw)
To: Yann Dirson; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <20070630194335.GK7730@nan92-1-81-57-214-146.fbx.proxad.net>
Yann Dirson <ydirson@altern.org> writes:
> On Sat, Jun 30, 2007 at 12:17:10PM -0700, Junio C Hamano wrote:
>> So I am somewhat negative on this, unless there is a way for
>> scripts to say "Even though I say 'git foo', I do mean 'git foo'
>> not whatever the user has aliased".
>
> "git --no-alias foo" (like "cvs -f foo" which ignores ~/.cvsrc) ?
The current scripts that largely use "git-foo" do not have to be
changed. Your --no-alias and Linus's "git - foo" would be a
"solution", but both require changes to the scripts -- and that
"solution" is necessary only because we would rewrite calls to
"git-foo" in existing scripts to "git foo" today?
No, thanks. We should do better than that.
^ permalink raw reply
* Re: [PATCH] git-clone: fetch possibly detached HEAD over dumb http
From: Junio C Hamano @ 2007-07-01 2:22 UTC (permalink / raw)
To: Alex Riesen; +Cc: skimo, git, Louis-Noel Pouchet
In-Reply-To: <20070630222336.GA2703@steel.home>
Alex Riesen <raa.lkml@gmail.com> writes:
> The check for .git validity includes checking if HEAD contains
> something sane, and this check is very simple: the HEAD is read
> (readlink(2) or plain read(2)) and tested if it contains a
> reference starting with "refs/", which maybe inconsistent with
> resolve_gitlink_ref, but probably ok.
Ah, I was not paying close attention to resolve_gitlink_ref();
if it does not require HEAD to point at refs/ I would say it is
a bug.
Come to think of it, I would further say that we probably should
tighten it up a bit: HEAD must be either a valid commit object
name (i.e. detached) or a ref that point at somewhere under
refs/heads hierarchy, not just anywhere in refs/.
^ permalink raw reply
* Re: Start deprecating "git-command" in favor of "git command"
From: eschvoca @ 2007-07-01 1:48 UTC (permalink / raw)
To: git
In-Reply-To: <20070701004517.31176.qmail@science.horizon.com>
By removing the dash I would miss out on man pages too. I don' t like
seeing all the rare commands pollute my PATH.
In zsh while I'm typing a command like:
$ git-rebase branch --
I then realize I need the man page so I type "Esc-h" and it appears.
When I exit man I'm back to the same spot in the command line.
e
^ permalink raw reply
* Re: Start deprecating "git-command" in favor of "git command"
From: linux @ 2007-07-01 0:45 UTC (permalink / raw)
To: git
H'm... I use the git-foo forms a lot so I can do easy history substitution.
In particular, "!git-grep" (actually, "!git-g") gets used a fair bit.
^ permalink raw reply
* Re: [PATCH (3rd try)] Add git-stash script
From: Johannes Schindelin @ 2007-07-01 0:16 UTC (permalink / raw)
To: しらいしななこ
Cc: Junio C Hamano, GIT
In-Reply-To: <200706302327.l5UNRMtc027974@mi0.bluebottle.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2267 bytes --]
Hi,
On Sun, 1 Jul 2007, しらいしななこ wrote:
> Quoting Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>
> > On Sat, 30 Jun 2007, しらいしななこ wrote:
> >
> >> diff --git a/git-stash.sh b/git-stash.sh
> >> [...]
> >> + printf >&2 'Saved WIP on %s\n' "$msg"
> >
> > You have an awful lot of printfs in the code. Why not just use echos?
>
> I just imitated other scripts. I can change it to
>
> echo >&2 "Saved WIP on $msg"
>
> but after reading Junio's comments, I think I probably should not.
You can leave them as-are, but I am actually more used to reading
something like
echo "Saved WIP on $msg" >&2
> >> +list_stash () {
> >> + git-log --pretty=oneline -g "$@" $ref_stash |
> >
> > Wouldn't you want "--default $ref_stash" here?
>
> I do not know, and I'm sorry I do not understand Junio's comments.
>
> What does --default do in this case?
I had the impression that
git stash list stash@{3}
would make sense. Probably I was mistaken.
> >> +apply_stash () {
> >> + git-diff-files --quiet ||
> >> + die 'Cannot restore on top of a dirty state'
> >
> > You meant "no_changes", right? I think you miss changes in the index
> > otherwise.
>
> After I read exchanges between you and Junio I do not know which way is
> preferred.
Well, there are two differing, and contradicting, preferences: Junio's and
mine.
Now you can have a third preference, but in the end what weighs most is
the opinion of the person implementing it.
> Using no_changes does not forbid me from doing that, but I think Junio's
> example will be forbidden. The original scenario was that I apply a
> stashed change to an unmodified state, and there is no problem either
> way.
Oh, but there is. Imagine this:
File "f" contains "1" in HEAD, "2" in the index and "3" in the working
directory. Now you say "git stash". Okay, file "f" now contains "1" in all
three, and the working directory is clean. Suppose you decide the stash
was a mistake. "git stash apply". File "f" contains "1" in _both_ the HEAD
and the index, and "3" in the working directory.
Now, you might say that it does not matter. But then we should not even
save the index.
Can I make one further request? Add "git stash save" to do the same as
"git stash"?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH (3rd try)] Add git-stash script
From: しらいしななこ @ 2007-06-30 23:27 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, GIT
In-Reply-To: <Pine.LNX.4.64.0706301641000.4438@racer.site>
Quoting Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> Hi,
Hello.
> On Sat, 30 Jun 2007, しらいしななこ wrote:
>
>> diff --git a/git-stash.sh b/git-stash.sh
>> [...]
>> + printf >&2 'Saved WIP on %s\n' "$msg"
>
> You have an awful lot of printfs in the code. Why not just use echos?
I just imitated other scripts. I can change it to
echo >&2 "Saved WIP on $msg"
but after reading Junio's comments, I think I probably should not.
>> +list_stash () {
>> + git-log --pretty=oneline -g "$@" $ref_stash |
>
> Wouldn't you want "--default $ref_stash" here?
I do not know, and I'm sorry I do not understand Junio's comments.
What does --default do in this case?
>> +apply_stash () {
>> + git-diff-files --quiet ||
>> + die 'Cannot restore on top of a dirty state'
>
> You meant "no_changes", right? I think you miss changes in the index
> otherwise.
After I read exchanges between you and Junio I do not know which way
is preferred. Using no_changes does not forbid me from doing that,
but I think Junio's example will be forbidden. The original scenario
was that I apply a stashed change to an unmodified state, and there is
no problem either way.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
----------------------------------------------------------------------
Free pop3 email with a spam filter.
http://www.bluebottle.com
^ permalink raw reply
* Re: Start deprecating "git-command" in favor of "git command"
From: walt @ 2007-06-30 22:40 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0706302236210.4438@racer.site>
Johannes Schindelin wrote:
> Hi,
>
> On Sat, 30 Jun 2007, walt wrote:
>
>> Linus Torvalds wrote:
>>> I realize that a lot of people use the "git-xyzzy" format, and we have
>>> various historical reasons for it...
>> One of the historical reasons was to allow users of gnu interactive
>> tools to delete the git wrapper script, as outlined in 'INSTALL'.
...
> All this would be less of a problem if Git consisted only of builtins,
> since you could easily do "mv git gitscm" then. *sigh*
I just installed the gnu tools as a test (gentoo won't allow both gits to
be installed at the same time, btw) and I found that each package installs
one main 'git' along with a collection of other tools beginning with the
prefix git.
One major difference is that our git names them git-* while the gnu tools
names them git*, so only the main 'git's conflict. The gnu 'git' can also
be renamed and it still works. 'man git' might still be a problem.
^ permalink raw reply
* Re: most commonly used git commands?
From: Alex Riesen @ 2007-06-30 22:35 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Johannes Sixt, git
In-Reply-To: <Pine.LNX.4.64.0706301531050.4438@racer.site>
Johannes Schindelin, Sat, Jun 30, 2007 16:31:48 +0200:
> On Sat, 30 Jun 2007, Alex Riesen wrote:
> > Johannes Schindelin, Thu, Jun 28, 2007 16:07:17 +0200:
> > > > No. It was meant as Alex said it. Windows (MinGW) doesn't understand
> > > > "chmod a+x blub".
> > >
> > > Yes, I suspected that. But I don't see a need for it on Windows (MinGW) to
> > > begin with.
> > >
> >
> > But it is necessary on Windows (Cygwin):
>
> I thought that on Cygwin, filemode=1? I mean, Cygwin _never_ had problems
> with chmod under my fingers.
>
Try doing stat(2) on file.txt which contains "#!/bin/sh" in its first
line and for which you have issued a chmod yet. Like a new file, or
like every file in a git-tracked directory after you did a fresh
checkout. Cygwin actually opens the files when doing stat(2), looks
inside and tries to guess if they are executable.
You should have said: "Cygwin _never_ had problems with chmod because
it cannot and didn't make it work". It is not just chmod, the other
side, stat, matters as well.
^ permalink raw reply
* Re: [PATCH] git-clone: fetch possibly detached HEAD over dumb http
From: Alex Riesen @ 2007-06-30 22:23 UTC (permalink / raw)
To: skimo; +Cc: Junio C Hamano, git, Louis-Noel Pouchet
In-Reply-To: <20070630134542.GF7969MdfPADPa@greensroom.kotnet.org>
Sven Verdoolaege, Sat, Jun 30, 2007 15:45:44 +0200:
> On Sat, Jun 30, 2007 at 03:33:10PM +0200, Alex Riesen wrote:
> > Sven Verdoolaege, Fri, Jun 29, 2007 10:31:08 +0200:
> > > + head_sha1=`cat "$GIT_DIR/REMOTE_HEAD"`
> > > + case "$head_sha1" in
> > > + 'ref: refs/'*)
> > > + ;;
> >
> > And what do you do if the HEAD is a reflink on something not in refs/?
> > Like "ref: tmp"? Yes, it is unlikely, but is not forbidden.
>
> It may not be forbidden, but I don't think it would
> work with current git-clone either.
>
Every command which needs a proper .git will not work, so I take this
back completely.
The check for .git validity includes checking if HEAD contains
something sane, and this check is very simple: the HEAD is read
(readlink(2) or plain read(2)) and tested if it contains a
reference starting with "refs/", which maybe inconsistent with
resolve_gitlink_ref, but probably ok.
^ permalink raw reply
* Re: Start deprecating "git-command" in favor of "git command"
From: Johannes Schindelin @ 2007-06-30 21:37 UTC (permalink / raw)
To: walt; +Cc: git
In-Reply-To: <f66eog$qe$1@sea.gmane.org>
Hi,
On Sat, 30 Jun 2007, walt wrote:
> Linus Torvalds wrote:
> > I realize that a lot of people use the "git-xyzzy" format, and we have
> > various historical reasons for it...
>
> One of the historical reasons was to allow users of gnu interactive
> tools to delete the git wrapper script, as outlined in 'INSTALL'.
>
> Seems unlikely that 'git' could still be deleted if your proposed
> changes are implemented. I recall that a few people cared a lot
> about this, and not too long ago.
All this would be less of a problem if Git consisted only of builtins,
since you could easily do "mv git gitscm" then. *sigh*
Ciao,
Dscho
^ permalink raw reply
* Concurrent modification breaks "racy git"
From: Matt McCutchen @ 2007-06-30 20:53 UTC (permalink / raw)
To: git, Petr Baudis
I found a case in which git fails to notice a modification to a file
in the working tree if the modification is concurrent with git-add.
The script below demonstrates it:
-----------
#!/bin/bash
set -x
rm -rf test
mkdir test
cd test
git-init-db
perl -e 'foreach $i (1...100) { open F, ">foo$i";
truncate F, 5000000; close F; }'
echo data1 >bar # Write bar...
git-add bar foo* &
sleep .1 # give git-add time to add it...
echo data2 >bar # and change it again in the same second!
# git-add takes a while to read foo*, so the index file gets a
# later timestamp, so git doesn't realize that bar's cleanliness
# is racy.
wait
git-diff bar # Now you don't see the difference...
touch bar
git-diff bar # Now you do!
-----------
I doubt this case will happen to anyone in practice, but I at least
wanted to make sure people knew about it. To fix it, git-add could
use a timestamp taken just before it starts reading files in place of
the mtime of the index.
Matt
^ permalink raw reply
* Re: Start deprecating "git-command" in favor of "git command"
From: walt @ 2007-06-30 20:34 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.LFD.0.98.0706301135300.1172@woody.linux-foundation.org>
Linus Torvalds wrote:
> I realize that a lot of people use the "git-xyzzy" format, and we have
> various historical reasons for it...
One of the historical reasons was to allow users of gnu interactive
tools to delete the git wrapper script, as outlined in 'INSTALL'.
Seems unlikely that 'git' could still be deleted if your proposed
changes are implemented. I recall that a few people cared a lot
about this, and not too long ago.
^ 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