* [PATCH] git-clone.txt: Fix grammar and formatting
From: Björn Gustavsson @ 2009-10-20 20:38 UTC (permalink / raw)
To: git; +Cc: gitster
Add the missing definite article ("the") in several places.
Change "note to..." to "note for...", since "note to" means that
that the note is addressed to someone (source: Google search).
Change "progressbar" to "progress bar" (source: Wikipedia).
Format git commands, options, and file names consistently using
back quotes (i.e. a fixed font in the resulting HTML document).
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
---
I am not a native English speaker, so if my attempted corrections
of the grammar is wrong, please correct me!
Documentation/git-clone.txt | 26 +++++++++++++-------------
1 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index 5ebcba1..7e7d9fc 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -39,7 +39,7 @@ OPTIONS
--local::
-l::
When the repository to clone from is on a local machine,
- this flag bypasses normal "git aware" transport
+ this flag bypasses the normal "git aware" transport
mechanism and clones the repository by making a copy of
HEAD and everything under objects and refs directories.
The files under `.git/objects/` directory are hardlinked
@@ -60,7 +60,7 @@ OPTIONS
-s::
When the repository to clone is on the local machine,
instead of using hard links, automatically setup
- .git/objects/info/alternates to share the objects
+ `.git/objects/info/alternates` to share the objects
with the source repository. The resulting repository
starts out without any object of its own.
+
@@ -69,7 +69,7 @@ it unless you understand what it does. If you clone your
repository using this option and then delete branches (or use any
other git command that makes any existing commit unreferenced) in the
source repository, some objects may become unreferenced (or dangling).
-These objects may be removed by normal git operations (such as 'git-commit')
+These objects may be removed by normal git operations (such as `git commit`)
which automatically call `git gc --auto`. (See linkgit:git-gc[1].)
If these objects are removed and were referenced by the cloned repository,
then the cloned repository will become corrupt.
@@ -86,13 +86,13 @@ objects from the source repository into a pack in the cloned repository.
--reference <repository>::
If the reference repository is on the local machine,
- automatically setup .git/objects/info/alternates to
+ automatically setup `.git/objects/info/alternates` to
obtain objects from the reference repository. Using
an already existing repository as an alternate will
require fewer objects to be copied from the repository
being cloned, reducing network and local storage costs.
+
-*NOTE*: see NOTE to --shared option.
+*NOTE*: see the NOTE for the `--shared` option.
--quiet::
-q::
@@ -101,7 +101,7 @@ objects from the source repository into a pack in the cloned repository.
--verbose::
-v::
- Display the progressbar, even in case the standard output is not
+ Display the progress bar, even in case the standard output is not
a terminal.
--no-checkout::
@@ -121,17 +121,17 @@ objects from the source repository into a pack in the cloned repository.
configuration variables are created.
--mirror::
- Set up a mirror of the remote repository. This implies --bare.
+ Set up a mirror of the remote repository. This implies `--bare`.
--origin <name>::
-o <name>::
- Instead of using the remote name 'origin' to keep track
- of the upstream repository, use <name>.
+ Instead of using the remote name `origin` to keep track
+ of the upstream repository, use `<name>`.
--branch <name>::
-b <name>::
Instead of pointing the newly created HEAD to the branch pointed
- to by the cloned repository's HEAD, point to <name> branch
+ to by the cloned repository's HEAD, point to `<name>` branch
instead. In a non-bare repository, this is the branch that will
be checked out.
@@ -158,7 +158,7 @@ objects from the source repository into a pack in the cloned repository.
--recursive::
After the clone is created, initialize all submodules within,
using their default settings. This is equivalent to running
- 'git submodule update --init --recursive' immediately after
+ `git submodule update --init --recursive` immediately after
the clone is finished. This option is ignored if the cloned
repository does not have a worktree/checkout (i.e. if any of
`--no-checkout`/`-n`, `--bare`, or `--mirror` is given)
@@ -171,8 +171,8 @@ objects from the source repository into a pack in the cloned repository.
<directory>::
The name of a new directory to clone into. The "humanish"
part of the source repository is used if no directory is
- explicitly given ("repo" for "/path/to/repo.git" and "foo"
- for "host.xz:foo/.git"). Cloning into an existing directory
+ explicitly given (`repo` for `/path/to/repo.git` and `foo`
+ for `host.xz:foo/.git`). Cloning into an existing directory
is only allowed if the directory is empty.
:git-clone: 1
--
1.6.5.1.2.g310c
^ permalink raw reply related
* Re: [PATCH] pull: refuse complete src:dst fetchspec arguments
From: Sean Estabrooks @ 2009-10-20 20:30 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <d561e70f0aa802ceb96eba16d3bb2316134d69c8.1256062808.git.trast@student.ethz.ch>
On Tue, 20 Oct 2009 20:23:06 +0200
Thomas Rast <trast@student.ethz.ch> wrote:
Hi Thomas,
> git-pull has historically accepted full fetchspecs, meaning that you
> could do
>
> git pull $repo A:B
>
> which would simultaneously fetch the remote branch A into the local
> branch B and merge B into HEAD. This got especially confusing if B
> was checked out. New users variously mistook pull for fetch or read
> that command as "merge the remote A into my B", neither of which is
> correct.
>
> Since the above usage should be very rare and can be done with
> separate calls to fetch and merge, we just disallow full fetchspecs in
> git-pull.
It is however a handy shortcut to be able to specify the full refspec
and specify where you want the head stored locally. It seems a shame to
throw away that functionality because of one confusing case. Wouldn't
it be better to test of the confusing case and instead error out if the
local refname is already checked out?
[...]
> diff --git a/t/t5520-pull.sh b/t/t5520-pull.sh
> index dd2ee84..a566a99 100755
> --- a/t/t5520-pull.sh
> +++ b/t/t5520-pull.sh
> @@ -29,18 +29,6 @@ test_expect_success 'checking the results' '
> diff file cloned/file
> '
>
> -test_expect_success 'pulling into void using master:master' '
> - mkdir cloned-uho &&
> - (
> - cd cloned-uho &&
> - git init &&
> - git pull .. master:master
> - ) &&
> - test -f file &&
> - test -f cloned-uho/file &&
> - test_cmp file cloned-uho/file
> -
> -
> test_expect_success 'test . as a remote' '
>
> git branch copy master &&
> --
>
Instead of removing this test it should be modified or replaced
with a test that ensures the new functionality operates correctly.
In this case that would mean checking that using a full refspec
errors out.
Cheers,
Sean
^ permalink raw reply
* Re: ident hash usage question
From: Alex Riesen @ 2009-10-20 20:35 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Eugene Sajine, git
In-Reply-To: <200910202222.37563.j6t@kdbg.org>
On Tue, Oct 20, 2009 at 22:22, Johannes Sixt <j6t@kdbg.org> wrote:
> On Dienstag, 20. Oktober 2009, Alex Riesen wrote:
>> What's so hard with storing the SHA-1 of the *commit*, anyway?
>
> The hard part is that you get a cycle: commit SHA1 depends on contents depends
> on commit SHA1.
Don't store it in the repo. Store it in the output.
^ permalink raw reply
* Re: ident hash usage question
From: Eugene Sajine @ 2009-10-20 20:30 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0910201219q4d16c472n43cab4b5d17cf63c@mail.gmail.com>
First, thank you for your answers!
>
> Very likely it isn't, but it's your choice.
;)
>
>> Because after having this hash one can build up all necessary info from it:
>
> Depending on your definition of "necessary".
I'm trying to find a way to get to state where i can do
$ git log <path>
Or any other variants of it without introducing any non-default
scripts/features/keywords and limiting keywords to one to avoid any
related problem...
One of my friends said that git is not working for their development
model... C++ development with static linking across the board, where
they need to see exactly which version of the file has got to the
executable. Roughly, they are using CVS' keywords and revision numbers
and a script wich matches them between two versions of the
executables.
I've got curious if Git can support it and how it can be done with
minimal changes to workflow.
>
>> #finding blobs with SHA indicated in $Id$ keword
>> $ git log --no-abbrev --raw --all | grep SHA-1
>
> yeah. These are all starting from commit which introduced
> the hash under a specific path, ending at the commit where
> the path contains another SHA-1.
Actually, grep "SHA-1 A" will show added path(s) only, so this is resolved
>
>> # little script or regexp here (don’t have it)
>> $ pull out path from result
>>
>> # last commit for the path with all corresponding info
>> $ git log -1 HEAD path
>>
>> So, this seems to cover most of the needs of people who would like to
>> use keywords expansion, if they are not ready to forget about them…
>>
>> Does it make sense?
>
> Not much. You'll always get a long list of commits which didn't
> change the damned blob. And you have absolutely no way
> to find out exactly which of the commits have produced
> the blob you're looking at (because you decided to do away
> with the information).
How is that? It seams to me that git log <path> will show only commits
where <path> was changed/committed? Considering the fact that I've got
the initial path from the blob, i should get the exact commit history
(or last commit in my example) for the file(s) (Files if renaming
occurred without content change).
Thanks,
Eugene
^ permalink raw reply
* Re: [PATCH] blame: make sure that the last line ends in an LF
From: Junio C Hamano @ 2009-10-20 20:28 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Junio C Hamano, Git List, Johannes Schindelin
In-Reply-To: <fabb9a1e0910201304j2730e6f3j1ebc5c17be07dd12@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> On Tue, Oct 20, 2009 at 11:55, Junio C Hamano <gitster@pobox.com> wrote:
>> That is kind of surprising ;-) as I do remember that I never thought about
>> this issue of dealing with the incomplete lines while writing the blame
>> algorithm. I actually didn't even think about "well this will not work
>> because I am ignoring the incomplete lines".
>
> I used the following repo for testing:
>
> $ git init
> Initialized empty Git repository in /home/sverre/code/test/.git/
> $ echo "first line" > test
> $ git add test
> $ git commit -m "initial"
> [master (root-commit) d573d06] initial
> 1 files changed, 1 insertions(+), 0 deletions(-)
> create mode 100644 test
> $ echo -n "second line, no newline" >> test
> $ git add test
> $ git commit -m "second"
> [master 76ad2f9] second
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> Regular output looks good:
>
> $ git blame test
> ^d573d06 (Sverre Rabbelier 2009-10-20 12:30:56 -0500 1) first line
> 76ad2f90 (Sverre Rabbelier 2009-10-20 12:31:57 -0500 2) second line, no newline
>
> Porcelain output looks good too:
>
> $ git blame -p test
> d573d06f0dd50148ba8e59bf8f1ef8fa7ee9fc88 1 1 1
> author Sverre Rabbelier
> author-mail <srabbelier@gmail.com>
> author-time 1256059856
> author-tz -0500
> committer Sverre Rabbelier
> committer-mail <srabbelier@gmail.com>
> committer-time 1256059856
> committer-tz -0500
> summary initial
> boundary
> filename test
> first line
> 76ad2f90bde689a65715e37afd37d45942c74954 2 2 1
> author Sverre Rabbelier
> author-mail <srabbelier@gmail.com>
> author-time 1256059917
> author-tz -0500
> committer Sverre Rabbelier
> committer-mail <srabbelier@gmail.com>
> committer-time 1256059917
> committer-tz -0500
> summary second
> previous d573d06f0dd50148ba8e59bf8f1ef8fa7ee9fc88 test
> filename test
> second line, no newline
Thanks.
For both styles of output, adding an extra LF after "no newline" would be
necessary to make the output legible (for human) and parsable (for
scripts).
In addition, it would help Porcelains to re-construct the final text if
you added a boolean "incomplete-line" (put it on its own line, immediately
after "filename test" line). Then they will know that LF after "second
line, no newline" was not there in the original and was added for
parsability.
I am not sure what we want to do for non-porcelain output (other than
adding the extra LF at the end). Assuming that they are meant to be read
by humans (and casual scripts that do not bother reading --porcelain
format), it might be best not to add any extra marking.
^ permalink raw reply
* Re: ident hash usage question
From: Johannes Sixt @ 2009-10-20 20:22 UTC (permalink / raw)
To: Alex Riesen; +Cc: Eugene Sajine, git
In-Reply-To: <81b0412b0910201219q4d16c472n43cab4b5d17cf63c@mail.gmail.com>
On Dienstag, 20. Oktober 2009, Alex Riesen wrote:
> What's so hard with storing the SHA-1 of the *commit*, anyway?
The hard part is that you get a cycle: commit SHA1 depends on contents depends
on commit SHA1.
-- Hannes
^ permalink raw reply
* Re: [PATCH] blame: make sure that the last line ends in an LF
From: Sverre Rabbelier @ 2009-10-20 20:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git List, Johannes Schindelin
In-Reply-To: <7vbpk2ovio.fsf@alter.siamese.dyndns.org>
Heya,
On Tue, Oct 20, 2009 at 11:55, Junio C Hamano <gitster@pobox.com> wrote:
> That is kind of surprising ;-) as I do remember that I never thought about
> this issue of dealing with the incomplete lines while writing the blame
> algorithm. I actually didn't even think about "well this will not work
> because I am ignoring the incomplete lines".
I used the following repo for testing:
$ git init
Initialized empty Git repository in /home/sverre/code/test/.git/
$ echo "first line" > test
$ git add test
$ git commit -m "initial"
[master (root-commit) d573d06] initial
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 test
$ echo -n "second line, no newline" >> test
$ git add test
$ git commit -m "second"
[master 76ad2f9] second
1 files changed, 1 insertions(+), 0 deletions(-)
Regular output looks good:
$ git blame test
^d573d06 (Sverre Rabbelier 2009-10-20 12:30:56 -0500 1) first line
76ad2f90 (Sverre Rabbelier 2009-10-20 12:31:57 -0500 2) second line, no newline
Porcelain output looks good too:
$ git blame -p test
d573d06f0dd50148ba8e59bf8f1ef8fa7ee9fc88 1 1 1
author Sverre Rabbelier
author-mail <srabbelier@gmail.com>
author-time 1256059856
author-tz -0500
committer Sverre Rabbelier
committer-mail <srabbelier@gmail.com>
committer-time 1256059856
committer-tz -0500
summary initial
boundary
filename test
first line
76ad2f90bde689a65715e37afd37d45942c74954 2 2 1
author Sverre Rabbelier
author-mail <srabbelier@gmail.com>
author-time 1256059917
author-tz -0500
committer Sverre Rabbelier
committer-mail <srabbelier@gmail.com>
committer-time 1256059917
committer-tz -0500
summary second
previous d573d06f0dd50148ba8e59bf8f1ef8fa7ee9fc88 test
filename test
second line, no newline
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [RFC] pull/fetch rename
From: Wesley J. Landaker @ 2009-10-20 19:59 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Björn Steinbrink
In-Reply-To: <200910201947.50423.trast@student.ethz.ch>
On Tuesday 20 October 2009 11:47:45 Thomas Rast wrote:
> Especially on IRC, we see many people who are some combination of
> misunderstanding, misusing or overusing git-pull. I figure this is
> the result of several factors, notably
>
> a) pull/push are not symmetric,
>
> b) guides/tutorials recommend pull for situations where they
> shouldn't,
>
> c) people blindly fire commands at git.
This may be minor, but also:
d) in mercurial, pull/push are symmetric, but fetch means pull+merge
> As you probably guessed by now, here is an idea for a very aggressive
> transition plan to address (a) in four phases:
I would love to see this change, not because I get confused about pull/fetch
(it honestly only took a few days to get used to), but because having
push/pull be symmetric just is so much more conceptually pure / easier
explain to co-workers / separation between orthogonal operations /
satisfying to my inner perfectionist / etc.
> 1. git-fetch gets options --merge/-m and --rebase that make it behave
> like (current) git-pull, but requiring explicit arguments.
> git-pull gets a new option --merge (-m) that only enforces presence
> of arguments.
>
> 2. git-pull refuses to do any work unless given either --merge or
> --rebase. Deprecation warnings for this start at the same time as
> (1.).
>
> 3. git-pull becomes a synonym for git-fetch.
>
> 4. git-fetch gives deprecation warnings that point the user to
> git-pull instead.
Hmmm, maybe this would be better for easier transition; replace 2-4 above
with:
2. git-pull learns --merge and gets a configuration option that allows
turning auto-merging off (e.g. pull.merge = merge/yes (default), rebase, or
no). This doesn't change any behavior by default, but allows individual
users to essentially make pull == fetch, and is forward compatible with
changes up to #4.
3. git-pull gives a deprecation warning if the configuration option is not
set, but otherwise defaults to merge. To get rid of the warning, you can set
it explicitly (one way or another).
4. The configuration option default changes to "no", and a helpful message
is printed telling you that you can set the configuration option to merge to
get the old behavior.
5. Drop deprecation messages. At this point, git fetch and git pull are
identical, except git fetch never merges, regardless of the pull
configuration setting.
This has a few nice properties:
* There is lots and lots of warning; this transition could happen slowly.
* Early on, it will be possible to make git pull have symmetric behavior
by default, which is the desired endgame.
* In the end, people who want "git pull" to always keep it's current
behavior can do so by setting the proper configuration variable.
* git fetch doesn't need to be deprecated (but could be).
^ permalink raw reply
* Re: Re: [RFC PATCH] hooks: add some defaults to support sane workflow to pre-commit
From: Heiko Voigt @ 2009-10-20 19:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4opv4vjh.fsf@alter.siamese.dyndns.org>
On Mon, Oct 19, 2009 at 01:50:26AM -0700, Junio C Hamano wrote:
> Heiko Voigt <git-list@hvoigt.net> writes:
>
> > It sometimes happens that you move to a new machine and forget to setup your
> > name and email address. To find this out after 10 commits can be quite
> > frustrating.
>
> Doesn't env_hint[] kick in in fmt_ident() in such a case, though?
It is not want you usually want. You get <username>@<hostname> as the
committer but if you are working on a workstation this is seldomly your
email address. At least in my experience.
I would like this as a safeguard that you have done some basic setup
before you create any commits.
cheers Heiko
^ permalink raw reply
* Re: [PATCH] blame: make sure that the last line ends in an LF
From: Johannes Schindelin @ 2009-10-20 19:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sverre Rabbelier, Git List
In-Reply-To: <7vbpk2ovio.fsf@alter.siamese.dyndns.org>
Hi,
On Tue, 20 Oct 2009, Junio C Hamano wrote:
> Sverre Rabbelier <srabbelier@gmail.com> writes:
>
> >> Or am I worrying too much?
> >
> > No, I think your concerns are valid, we should go with (2) and DTRT.
> > Does the updated patch address your concerns? If so I can send a new
> > version.
>
> Assuming the internal blame algorithm correctly works with such an
> input, I'd be happier with an approach to allow users to tell the
> difference. The --porcelain output was designed to be extensible, and it
> might make sense to show the "this line is incomplete" as a separate
> bit, though.
Sorry, you lost me. If, say, line 614 is the last line that does not end
in a new line, if I ask for it to be blamed, I want to know who is
responsible for the current form of line 614.
Not whether the line ends in a new line or not.
Ciao,
Dscho
^ permalink raw reply
* Re: git hang with corrupted .pack
From: Junio C Hamano @ 2009-10-20 19:33 UTC (permalink / raw)
To: Shawn O. Pearce, Nicolas Pitre; +Cc: Andy Isaacson, git, Alex Riesen
In-Reply-To: <7vzl7mng35.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>>> We now abort the loop if inflate() returns Z_BUF_ERROR without
>>> consuming the entire input buffer it was given, or has filled
>>> the entire output buffer but has not yet returned Z_STREAM_END.
>>> Either state is a clear indicator that this loop is not working
>>> as expected, and should not continue.
>>
>> When the inflated contents is of size 0, avail_out would be 0 and avail_in
>> would still have something because the input stream needs to have the end
>> of stream marker that is more than zero byte long.
>
> After thinking about this a bit more, I am reasonably sure that this is
> it. The contents does not have to be a 0-length string, but you would hit
> this if the pure-data portion of the deflated stream aligns at the end of
> your (un)pack window and it happens to require another use_pack() to move
> the window to read the end-of-stream signal. In that situation, the
> output buffer has already been filled, but you haven't read the input
> stream fully. Would't the new check incorrectly trigger in such a case?
>
>>> st = git_inflate(&stream, Z_FINISH);
>>> + if (st == Z_BUF_ERROR && (stream.avail_in || !stream.avail_out))
>>> + break;
>
> We won't see this on 64-bit platforms because we use larger (un)pack
> window and the condition is much less likely to be met.
Perhaps it would be as simple as this?
We deliberately give one byte more than what we expect to see and error
out when we do get that extra byte filled.
sha1_file.c | 17 +++++++++--------
1 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index 4cc8939..8c9f392 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1344,7 +1344,7 @@ unsigned long get_size_from_delta(struct packed_git *p,
off_t curpos)
{
const unsigned char *data;
- unsigned char delta_head[20], *in;
+ unsigned char delta_head[21], *in;
z_stream stream;
int st;
@@ -1357,13 +1357,14 @@ unsigned long get_size_from_delta(struct packed_git *p,
in = use_pack(p, w_curs, curpos, &stream.avail_in);
stream.next_in = in;
st = git_inflate(&stream, Z_FINISH);
- if (st == Z_BUF_ERROR && (stream.avail_in || !stream.avail_out))
- break;
+ if (!stream.avail_out)
+ break; /* the payload is larger than it should be! */
curpos += stream.next_in - in;
} while ((st == Z_OK || st == Z_BUF_ERROR) &&
- stream.total_out < sizeof(delta_head));
+ stream.total_out < (sizeof(delta_head) - 1));
git_inflate_end(&stream);
- if ((st != Z_STREAM_END) && stream.total_out != sizeof(delta_head)) {
+ if ((st != Z_STREAM_END) &&
+ stream.total_out != sizeof(delta_head) - 1) {
error("delta data unpack-initial failed");
return 0;
}
@@ -1589,15 +1590,15 @@ static void *unpack_compressed_entry(struct packed_git *p,
buffer[size] = 0;
memset(&stream, 0, sizeof(stream));
stream.next_out = buffer;
- stream.avail_out = size;
+ stream.avail_out = size + 1;
git_inflate_init(&stream);
do {
in = use_pack(p, w_curs, curpos, &stream.avail_in);
stream.next_in = in;
st = git_inflate(&stream, Z_FINISH);
- if (st == Z_BUF_ERROR && (stream.avail_in || !stream.avail_out))
- break;
+ if (!stream.avail_out)
+ break; /* the payload is larger than it should be! */
curpos += stream.next_in - in;
} while (st == Z_OK || st == Z_BUF_ERROR);
git_inflate_end(&stream);
^ permalink raw reply related
* Re: [PATCH] pull: refuse complete src:dst fetchspec arguments
From: Wesley J. Landaker @ 2009-10-20 19:29 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <d561e70f0aa802ceb96eba16d3bb2316134d69c8.1256062808.git.trast@student.ethz.ch>
On Tuesday 20 October 2009 12:23:06 Thomas Rast wrote:
> git-pull has historically accepted full fetchspecs, meaning that you
> could do
>
> git pull $repo A:B
>
> which would simultaneously fetch the remote branch A into the local
> branch B and merge B into HEAD. This got especially confusing if B
> was checked out. New users variously mistook pull for fetch or read
> that command as "merge the remote A into my B", neither of which is
> correct.
One thought here is that if the change you suggested (and I personally like)
in your "[RFC] pull/fetch rename" thread was made, then I would expect to be
able to run this exact command to have git fetch the remote branch A into
the local branch B (with no merging taking place, because I didn't say --
merge). So basically, it would be like "git fetch $repo A:B" is now.
I readily agree that the *current* behavior of that command would have
probably caught me off-guard, since I probably only would have typed that on
accident (e.g. using "pull" when I meant "fetch").
^ permalink raw reply
* Re: ident hash usage question
From: Alex Riesen @ 2009-10-20 19:19 UTC (permalink / raw)
To: Eugene Sajine; +Cc: git
In-Reply-To: <76c5b8580910201159i75a90f28pb882e83f0c7c40ae@mail.gmail.com>
On Tue, Oct 20, 2009 at 20:59, Eugene Sajine <euguess@gmail.com> wrote:
>>
>> Well, not exactly impossible, but you can end up with multiple paths,
>> some of which may not have anything to do the original path.
>>
>> Just run git log --no-abbrev --raw --all and grep for the SHA-1
>
> This is exactly what I was looking for! Thank you!
>
Very likely it isn't, but it's your choice.
> Because after having this hash one can build up all necessary info from it:
Depending on your definition of "necessary".
> #finding blobs with SHA indicated in $Id$ keword
> $ git log --no-abbrev --raw --all | grep SHA-1
yeah. These are all starting from commit which introduced
the hash under a specific path, ending at the commit where
the path contains another SHA-1.
> # little script or regexp here (don’t have it)
> $ pull out path from result
>
> # last commit for the path with all corresponding info
> $ git log -1 HEAD path
>
> So, this seems to cover most of the needs of people who would like to
> use keywords expansion, if they are not ready to forget about them…
>
> Does it make sense?
Not much. You'll always get a long list of commits which didn't
change the damned blob. And you have absolutely no way
to find out exactly which of the commits have produced
the blob you're looking at (because you decided to do away
with the information).
What's so hard with storing the SHA-1 of the *commit*, anyway?
^ permalink raw reply
* Re: [RFC/PATCH] fsck: default to "git fsck --full"
From: Junio C Hamano @ 2009-10-20 19:11 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Junio C Hamano, Matthieu Moy, Johannes Schindelin, Alex Riesen,
Johannes Sixt, Sergio Callegari, git
In-Reply-To: <alpine.LFD.2.00.0910201457310.21460@xanadu.home>
Nicolas Pitre <nico@fluxnic.net> writes:
> On Tue, 20 Oct 2009, Junio C Hamano wrote:
>
>> diff --git a/Documentation/RelNotes-1.6.6.txt b/Documentation/RelNotes-1.6.6.txt
>> index 5f1fecb..1896e05 100644
>> --- a/Documentation/RelNotes-1.6.6.txt
>> +++ b/Documentation/RelNotes-1.6.6.txt
>> @@ -1,6 +1,13 @@
>> GIT v1.6.6 Release Notes
>> ========================
>>
>> +In this release, "git fsck" defaults to "git fsck --full" and checks
>> +packfiles. If you prefer a quicker check only on loose objects (the
> ^^
>
> Might be worth mentioning explicitly that, because of that change, plain
> fsck is now going to take much longer to complete.
Sounds fair; thanks.
diff --git a/Documentation/RelNotes-1.6.6.txt b/Documentation/RelNotes-1.6.6.txt
index 0adf998..fa0e11a 100644
--- a/Documentation/RelNotes-1.6.6.txt
+++ b/Documentation/RelNotes-1.6.6.txt
@@ -2,7 +2,8 @@ GIT v1.6.6 Release Notes
========================
In this release, "git fsck" defaults to "git fsck --full" and checks
-packfiles. If you prefer a quicker check only on loose objects (the
+packfiles, and because of this it will take much longer to complete
+than before. If you prefer a quicker check only on loose objects (the
old default), you can say "git fsck --no-full". This has been
supported by 1.5.4 and newer versions of git, so it is safe to write
it in your script even if you use slightly older git on some of your
^ permalink raw reply related
* Re: [RFC/PATCH] fsck: default to "git fsck --full"
From: Nicolas Pitre @ 2009-10-20 19:00 UTC (permalink / raw)
To: Junio C Hamano
Cc: Matthieu Moy, Johannes Schindelin, Alex Riesen, Johannes Sixt,
Sergio Callegari, git
In-Reply-To: <7v3a5doqcg.fsf_-_@alter.siamese.dyndns.org>
On Tue, 20 Oct 2009, Junio C Hamano wrote:
> diff --git a/Documentation/RelNotes-1.6.6.txt b/Documentation/RelNotes-1.6.6.txt
> index 5f1fecb..1896e05 100644
> --- a/Documentation/RelNotes-1.6.6.txt
> +++ b/Documentation/RelNotes-1.6.6.txt
> @@ -1,6 +1,13 @@
> GIT v1.6.6 Release Notes
> ========================
>
> +In this release, "git fsck" defaults to "git fsck --full" and checks
> +packfiles. If you prefer a quicker check only on loose objects (the
^^
Might be worth mentioning explicitly that, because of that change, plain
fsck is now going to take much longer to complete.
Nicolas
^ permalink raw reply
* Re: ident hash usage question
From: Eugene Sajine @ 2009-10-20 18:59 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Eugene Sajine
In-Reply-To: <81b0412b0910201119w7583487ag276cf964d0a85e@mail.gmail.com>
>
> Well, not exactly impossible, but you can end up with multiple paths,
> some of which may not have anything to do the original path.
>
> Just run git log --no-abbrev --raw --all and grep for the SHA-1
>
This is exactly what I was looking for! Thank you!
I understand that in some cases this can give me two paths instead of
one, but it will only demonstrate that I have absolute copy of a file
inside my repo, which is also good to diagnose (because the
probability of having two meaningful files with the same hash, but
different content is way too low).
So, this means that after few little tricks the keyword expansion
problem may be resolved by only using $Id$ keyword.
Because after having this hash one can build up all necessary info from it:
#finding blobs with SHA indicated in $Id$ keword
$ git log --no-abbrev --raw --all | grep SHA-1
# little script or regexp here (don’t have it)
$ pull out path from result
# last commit for the path with all corresponding info
$ git log -1 HEAD path
So, this seems to cover most of the needs of people who would like to
use keywords expansion, if they are not ready to forget about them…
Does it make sense?
Thanks,
Eugene
^ permalink raw reply
* [RFC/PATCH] fsck: default to "git fsck --full"
From: Junio C Hamano @ 2009-10-20 18:46 UTC (permalink / raw)
To: Matthieu Moy
Cc: Johannes Schindelin, Alex Riesen, Johannes Sixt, Sergio Callegari,
git
In-Reply-To: <vpq1vkygtx6.fsf@bauges.imag.fr>
Linus and other git developers from the early days trained their fingers
to type the command, every once in a while even without thinking, to check
the consistency of the repository back when the lower core part of the git
was still being developed. Developers who wanted to make sure that git
correctly dealt with packfiles could deliberately trigger their creation
and checked them after they were created carefully, but loose objects are
the ones that are written by various commands from random codepaths. It
made some technical sense to have a mode that checked only loose objects
from the debugging point of view for that reason.
Even for git developers, there no longer is any reason to type "git fsck"
every five minutes these days, worried that some newly created objects
might be corrupt due to recent change to git.
The reason we did not make "--full" the default is probably we trust our
filesystems a bit too much. At least, we trusted filesystems more than we
trusted the lower core part of git that was under development.
Once a packfile is created and we always use it read-only, there didn't
seem to be much point in suspecting that the underlying filesystems or
disks may corrupt them in such a way that is not caught by the SHA-1
checksum over the entire packfile and per object checksum. That trust in
the filesystems might have been a good tradeoff between fsck performance
and reliability on platforms git was initially developed on and for, but
it may not be true anymore as we run on many more platforms these days.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> ...
>> On Tue, 20 Oct 2009, Alex Riesen wrote:
>> ...
>>> --no-full works
>>
>> It works. Technically. For human users, though, --loose-objects-only
>> (with a shortcut "--loose") would be better.
>
> OTOH, the advantage of "--no-full" is that it's compatible with
> existing Git versions. If I learn Git 1.6.6 with --no-full, and use it
> in a script, then my stript works also with older Gits.
>
> But anyway, I think very few people are actually interested in "git
> --no-full" (or call it whatever you like), so I don't think this is
> very important.
For human users, I think --full vs --no-full is quite a nice suggestion,
given that we already have advertised --full and people know the option.
Also people know that splicing "no-" after the double dash is often the
way to negate a boolean-looking option.
The actual patch to do this is tiny, but that is just a bonus ;-)
Documentation/RelNotes-1.6.6.txt | 10 ++++++++++
Documentation/git-fsck.txt | 5 +++--
builtin-fsck.c | 2 +-
3 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/Documentation/RelNotes-1.6.6.txt b/Documentation/RelNotes-1.6.6.txt
index 5f1fecb..1896e05 100644
--- a/Documentation/RelNotes-1.6.6.txt
+++ b/Documentation/RelNotes-1.6.6.txt
@@ -1,6 +1,13 @@
GIT v1.6.6 Release Notes
========================
+In this release, "git fsck" defaults to "git fsck --full" and checks
+packfiles. If you prefer a quicker check only on loose objects (the
+old default), you can say "git fsck --no-full". This has been
+supported by 1.5.4 and newer versions of git, so it is safe to write
+it in your script if you use slightly older git on some of your
+machines.
+
In git 1.7.0, which is planned to be the release after 1.6.6, "git
push" into a branch that is currently checked out will be refused by
default.
@@ -38,6 +45,9 @@ Updates since v1.6.5
(usability, bells and whistles)
+ * "git fsck" by default checks the packfiles (i.e. "--full" is the
+ default); you can turn it off with "git fsck --no-full".
+
* "git log --decorate" shows the location of HEAD as well.
(developers)
diff --git a/Documentation/git-fsck.txt b/Documentation/git-fsck.txt
index 287c4fc..6fe9484 100644
--- a/Documentation/git-fsck.txt
+++ b/Documentation/git-fsck.txt
@@ -10,7 +10,7 @@ SYNOPSIS
--------
[verse]
'git fsck' [--tags] [--root] [--unreachable] [--cache] [--no-reflogs]
- [--full] [--strict] [--verbose] [--lost-found] [<object>*]
+ [--[no-]full] [--strict] [--verbose] [--lost-found] [<object>*]
DESCRIPTION
-----------
@@ -52,7 +52,8 @@ index file, all SHA1 references in .git/refs/*, and all reflogs (unless
or $GIT_DIR/objects/info/alternates,
and in packed git archives found in $GIT_DIR/objects/pack
and corresponding pack subdirectories in alternate
- object pools.
+ object pools. This is now default; you can turn it off
+ with --no-full.
--strict::
Enable more strict checking, namely to catch a file mode
diff --git a/builtin-fsck.c b/builtin-fsck.c
index c58b0e3..2d88e45 100644
--- a/builtin-fsck.c
+++ b/builtin-fsck.c
@@ -19,7 +19,7 @@ static int show_root;
static int show_tags;
static int show_unreachable;
static int include_reflogs = 1;
-static int check_full;
+static int check_full = 1;
static int check_strict;
static int keep_cache_objects;
static unsigned char head_sha1[20];
^ permalink raw reply related
* Re: [RFC! PATCH] pull: refuse complete src:dst fetchspec arguments
From: Thomas Rast @ 2009-10-20 18:37 UTC (permalink / raw)
To: git
In-Reply-To: <d561e70f0aa802ceb96eba16d3bb2316134d69c8.1256062808.git.trast@student.ethz.ch>
Thomas Rast wrote:
> git-pull has historically accepted full fetchspecs, meaning that you
> could do
>
> git pull $repo A:B
>
> which would simultaneously fetch the remote branch A into the local
> branch B and merge B into HEAD. This got especially confusing if B
> was checked out. New users variously mistook pull for fetch or read
> that command as "merge the remote A into my B", neither of which is
> correct.
>
> Since the above usage should be very rare and can be done with
> separate calls to fetch and merge, we just disallow full fetchspecs in
> git-pull.
>
> Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Argh. This was actually supposed to be an *RFC* patch.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* [PATCH] pull: refuse complete src:dst fetchspec arguments
From: Thomas Rast @ 2009-10-20 18:23 UTC (permalink / raw)
To: git
git-pull has historically accepted full fetchspecs, meaning that you
could do
git pull $repo A:B
which would simultaneously fetch the remote branch A into the local
branch B and merge B into HEAD. This got especially confusing if B
was checked out. New users variously mistook pull for fetch or read
that command as "merge the remote A into my B", neither of which is
correct.
Since the above usage should be very rare and can be done with
separate calls to fetch and merge, we just disallow full fetchspecs in
git-pull.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
This actually came up on IRC *twice* this week.
git-pull.sh | 19 +++++++++++++++++++
t/t5520-pull.sh | 12 ------------
2 files changed, 19 insertions(+), 12 deletions(-)
diff --git a/git-pull.sh b/git-pull.sh
index fc78592..8f06491 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -131,6 +131,25 @@ error_on_no_merge_candidates () {
exit 1
}
+check_full_fetchspec () {
+ shift # discard remote argument, if any
+ for arg in "$@"
+ do
+ case "$arg" in
+ *:*)
+ echo "$arg"
+ return
+ ;;
+ esac
+ done
+}
+
+full_fetchspec=$(check_full_fetchspec "$@")
+if test -n "$full_fetchspec"
+then
+ die "full fetchspec '$full_fetchspec' not allowed"
+fi
+
test true = "$rebase" && {
if ! git rev-parse -q --verify HEAD >/dev/null
then
diff --git a/t/t5520-pull.sh b/t/t5520-pull.sh
index dd2ee84..a566a99 100755
--- a/t/t5520-pull.sh
+++ b/t/t5520-pull.sh
@@ -29,18 +29,6 @@ test_expect_success 'checking the results' '
diff file cloned/file
'
-test_expect_success 'pulling into void using master:master' '
- mkdir cloned-uho &&
- (
- cd cloned-uho &&
- git init &&
- git pull .. master:master
- ) &&
- test -f file &&
- test -f cloned-uho/file &&
- test_cmp file cloned-uho/file
-'
-
test_expect_success 'test . as a remote' '
git branch copy master &&
--
1.6.5.1.144.g40216
^ permalink raw reply related
* Re: ident hash usage question
From: Alex Riesen @ 2009-10-20 18:19 UTC (permalink / raw)
To: Eugene Sajine; +Cc: git
In-Reply-To: <81b0412b0910201116s694d7877rda872b368f1ae09a@mail.gmail.com>
On Tue, Oct 20, 2009 at 20:16, Alex Riesen <raa.lkml@gmail.com> wrote:
> On Tue, Oct 20, 2009 at 19:24, Eugene Sajine <euguess@gmail.com> wrote:
>> I was able to get the $Id$ keyword to show the SHA-1 hash of the file
>> content, which is done using ident in gitattributes. Now I’m trying to
>> find a way to get more info about the file using only this hash.
>>
>> Could you , please, advise if there is a way to get file name and path
>> inside the repo by having only this Blob hash?
>
> It is not possible.
>
Well, not exactly impossible, but you can end up with multiple paths,
some of which may not have anything to do the original path.
Just run git log --no-abbrev --raw --all and grep for the SHA-1
^ permalink raw reply
* Re: ident hash usage question
From: Alex Riesen @ 2009-10-20 18:16 UTC (permalink / raw)
To: Eugene Sajine; +Cc: git
In-Reply-To: <76c5b8580910201024x58ffdd3bs6f4cc6932ac31868@mail.gmail.com>
On Tue, Oct 20, 2009 at 19:24, Eugene Sajine <euguess@gmail.com> wrote:
> I was able to get the $Id$ keyword to show the SHA-1 hash of the file
> content, which is done using ident in gitattributes. Now I’m trying to
> find a way to get more info about the file using only this hash.
>
> Could you , please, advise if there is a way to get file name and path
> inside the repo by having only this Blob hash?
It is not possible.
But you can save the commits hash in your blob. Then you'll have everything.
That how git knows it's version.
^ permalink raw reply
* [RFC] pull/fetch rename
From: Thomas Rast @ 2009-10-20 17:47 UTC (permalink / raw)
To: git; +Cc: Björn Steinbrink
Hi all,
While everyone is busy in two other UI threads, I figured I might as
well toss up another (probably) controversial topic.
Especially on IRC, we see many people who are some combination of
misunderstanding, misusing or overusing git-pull. I figure this is
the result of several factors, notably
a) pull/push are not symmetric,
b) guides/tutorials recommend pull for situations where they
shouldn't,
c) people blindly fire commands at git.
While the latter two are probably hopeless, I find (a) rather
annoying. It breaks everyone's intuition of git-pull when they first
see it. (I know that BK has a pull that also merges, but I gather
from the manual [never used it] that you cannot do the equivalent of
git-fetch in BK.)
As you probably guessed by now, here is an idea for a very aggressive
transition plan to address (a) in four phases:
1. git-fetch gets options --merge/-m and --rebase that make it behave
like (current) git-pull, but requiring explicit arguments.
git-pull gets a new option --merge (-m) that only enforces presence
of arguments.
2. git-pull refuses to do any work unless given either --merge or
--rebase. Deprecation warnings for this start at the same time as
(1.).
3. git-pull becomes a synonym for git-fetch.
4. git-fetch gives deprecation warnings that point the user to
git-pull instead.
(1.) is probably harmless and could be put into any particular
release. (2.) obviously breaks everyone's favourite script and needs
to fall on a major release. (3.) should be delayed significantly from
(2.) to allow time to expose such breakage, and similarly (4.) should
be delayed after (3.) (or just ignored, but in any case git-pull would
become the preferred spelling).
As you probably noticed, while 'git pull $remote $ref' only needs to
be changed to 'git pull --merge $remote $ref', this leaves a gap at
the current functionality of 'git pull' without arguments. Björn laid
out a nice suggestion for a git-update in
http://article.gmane.org/gmane.comp.version-control.git/130679
briefly summarised as: git-update would cover what 'git pull' (without
arguments) does right now. However, it could also be restricted to
fast-forward updates by default (with per-branch configurability as
with current git-pull).
Comments? Flames? Improvements?
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* ident hash usage question
From: Eugene Sajine @ 2009-10-20 17:24 UTC (permalink / raw)
To: git; +Cc: Eugene Sajine
Hi,
Please correct me if I’m missing something, but:
I was able to get the $Id$ keyword to show the SHA-1 hash of the file
content, which is done using ident in gitattributes. Now I’m trying to
find a way to get more info about the file using only this hash.
Could you , please, advise if there is a way to get file name and path
inside the repo by having only this Blob hash?
Thank you,
Eugene
^ permalink raw reply
* Re: git hang with corrupted .pack
From: Junio C Hamano @ 2009-10-20 17:13 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Andy Isaacson, git, Nicolas Pitre, Alex Riesen
In-Reply-To: <7viqeaovmp.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
>> We now abort the loop if inflate() returns Z_BUF_ERROR without
>> consuming the entire input buffer it was given, or has filled
>> the entire output buffer but has not yet returned Z_STREAM_END.
>> Either state is a clear indicator that this loop is not working
>> as expected, and should not continue.
>
> When the inflated contents is of size 0, avail_out would be 0 and avail_in
> would still have something because the input stream needs to have the end
> of stream marker that is more than zero byte long.
After thinking about this a bit more, I am reasonably sure that this is
it. The contents does not have to be a 0-length string, but you would hit
this if the pure-data portion of the deflated stream aligns at the end of
your (un)pack window and it happens to require another use_pack() to move
the window to read the end-of-stream signal. In that situation, the
output buffer has already been filled, but you haven't read the input
stream fully. Would't the new check incorrectly trigger in such a case?
>> st = git_inflate(&stream, Z_FINISH);
>> + if (st == Z_BUF_ERROR && (stream.avail_in || !stream.avail_out))
>> + break;
We won't see this on 64-bit platforms because we use larger (un)pack
window and the condition is much less likely to be met.
^ permalink raw reply
* Re: [RFC PATCH] git-gui: Allow staging multiple lines at once
From: Dirk Süsserott @ 2009-10-20 17:09 UTC (permalink / raw)
To: Jeff Epler; +Cc: git
In-Reply-To: <20091019195456.GA11121@unpythonic.net>
Am 19.10.2009 21:54 schrieb Jeff Epler:
> When applying less than a full hunk, it's still often desirable to apply
> a number of consecutive lines.
>
> This change makes it possible to sweep out a range of lines in the diff view
> with the left mouse button, then right click and "Stage Lines For Commit".
>
> The selected lines may span multiple hunks.
>
Awesome! I've been waiting for that very feature. Thanks in advance.
-- Dirk
^ 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