* Re: What's cooking in git.git (topics)
From: J. Bruce Fields @ 2007-11-25 23:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, Jeff King, Johannes Schindelin, git
In-Reply-To: <7v63zqj6bj.fsf@gitster.siamese.dyndns.org>
On Sun, Nov 25, 2007 at 02:42:08PM -0800, Junio C Hamano wrote:
> "J. Bruce Fields" <bfields@fieldses.org> writes:
>
> > Anyway, here's a first draft.
> >
> > --b.
> >
> > diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> > index 8355cce..7544715 100644
> > --- a/Documentation/user-manual.txt
> > +++ b/Documentation/user-manual.txt
> > ...
> > +Normally whenever a branch head in a public repository is modified, it
> > +is modified to point to a descendent of the commit that it pointed to
> > +before. By forcing a push in this situation, you break that convention.
> > +(See <<problems-with-rewriting-history>>).
> > +
> > +Nevertheless, this is a common practice for people that need a simple
> > +way to publish a work-in-progress patch series, and it is an acceptable
> > +compromise as long as you warn other developers that this is how you
> > +intend to manage the branch.
>
> Note that modern git allows repository owners to forbid such a forced
> non fast forward push at the receiving end. In such a case, you cannot
> even force a push.
>
> Instead, you would need to fetch the current branch tip from the remote
> and merge it into the branch you were tring to push, possibly using the
> "ours" merge strategy, before pushing it again. Use of "ours" merge in
> such a case:
>
> - makes the next fetch by other people properly fast-forwarding;
>
> - records your admission of guilt: "I screwed up the last push and
> this is a replacement --- this is what I really should have pushed
> the last time".
>
> - makes the resulting tree exactly the same as what you tried to push
> unsuccessfully. This is a valid substitute to a forced push in that
> it reverts the mistakes _you_ made with the previous push.
OK, that's interesting. In a similar vein, I've been experimenting with
"merge -s ours" lately as a way to keep track of the "meta-history" of
an unsubmitted patch series in progress. It seems a little hairy right
now, but maybe it'll turn out to be The Right Thing to do.
I don't want to deal with this in the manual yet. For the sake of
keeping things simple, I'd rather first stick to the case of a public
repository set up by the user which the user controls. And I think that
kind of use of "-s ours" is worth documenting but I'm not sure how to
deal with it yet.
--b.
^ permalink raw reply
* [PATCH] revert/cherry-pick: do not mention the original ref
From: Junio C Hamano @ 2007-11-25 23:15 UTC (permalink / raw)
To: git
When you cherry-pick or revert a commit, naming it with an annotated
tag, we added a comment, attempting to repeat what we got from the end
user, to the message.
But this was inconsistent. When we got "cherry-pick branch", we
recorded the object name (40-letter SHA-1) without saying anything like
"original was 'branch'". There was no need to. Also recent rewrite to
use parse-options made it impossible to parrot the original command line
without "unparsing".
This removes the code that implements the misguided "we dereferenced the
tag so record that in the commit message" behaviour.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-revert.c | 14 +-------------
1 files changed, 1 insertions(+), 13 deletions(-)
diff --git a/builtin-revert.c b/builtin-revert.c
index 365b330..a0586f9 100644
--- a/builtin-revert.c
+++ b/builtin-revert.c
@@ -30,7 +30,7 @@ static const char * const cherry_pick_usage[] = {
NULL
};
-static int edit, no_replay, no_commit, needed_deref, mainline;
+static int edit, no_replay, no_commit, mainline;
static enum { REVERT, CHERRY_PICK } action;
static struct commit *commit;
@@ -66,7 +66,6 @@ static void parse_args(int argc, const char **argv)
if (commit->object.type == OBJ_TAG) {
commit = (struct commit *)
deref_tag((struct object *)commit, arg, strlen(arg));
- needed_deref = 1;
}
if (commit->object.type != OBJ_COMMIT)
die ("'%s' does not point to a commit", arg);
@@ -333,17 +332,6 @@ static int revert_or_cherry_pick(int argc, const char **argv)
add_to_msg(")\n");
}
}
- if (needed_deref) {
- add_to_msg("(original 'git ");
- add_to_msg(me);
- add_to_msg("' arguments: ");
- for (i = 0; i < argc; i++) {
- if (i)
- add_to_msg(" ");
- add_to_msg(argv[i]);
- }
- add_to_msg(")\n");
- }
if (merge_recursive(sha1_to_hex(base->object.sha1),
sha1_to_hex(head), "HEAD",
^ permalink raw reply related
* [PATCH] "git-tag -s" should create a signed annotated tag
From: Junio C Hamano @ 2007-11-25 23:21 UTC (permalink / raw)
To: git; +Cc: Carlos Rica
The earlier patch 396865859918e9c7bf8ce74aae137c57da134610 (Make
builtin-tag.c use parse_options.) broke "git-tag -s".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* It's _very_ disturbing that the testsuite did not catch this
breakage, even though I though we had a very detailed coverage for
"git tag" when it was rewritten in C.
builtin-tag.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/builtin-tag.c b/builtin-tag.c
index 3a6467d..114c684 100644
--- a/builtin-tag.c
+++ b/builtin-tag.c
@@ -398,6 +398,9 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
argc = parse_options(argc, argv, options, git_tag_usage, 0);
+ if (sign)
+ annotate = 1;
+
if (list)
return list_tags(list == no_pattern ? NULL : list, lines);
if (delete)
^ permalink raw reply related
* Re: [RFC] best way to show diff of commit
From: David Brown @ 2007-11-25 23:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pierre Habouzit, J. Bruce Fields, Git ML
In-Reply-To: <7vfxyuj70i.fsf@gitster.siamese.dyndns.org>
On Sun, Nov 25, 2007 at 02:27:09PM -0800, Junio C Hamano wrote:
>Pierre Habouzit <madcoder@debian.org> writes:
>
>> Hmm it doesn't because I would have to call git commit -v each time I
>> commit and well I _like_ having the status better. And moreover I want
>> the diff to go in a separated buffer too.
>
>I've never felt it a problem while editing the log message in Emacs.
>
>Don't enhanced vi implementations let you split the same buffer into
>two allowing you to view different portions of it these days?
Yes, certainly with vim, which is what most distributions seem to include
as the enhanced vim. I have noticed that there seem to be fewer vim users
that figure out these kinds of things than emacs users, though.
Dave
^ permalink raw reply
* Re: [RFC] best way to show diff of commit
From: Pierre Habouzit @ 2007-11-25 23:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: J. Bruce Fields, Git ML
In-Reply-To: <7v1waej5ub.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1582 bytes --]
On Sun, Nov 25, 2007 at 10:52:28PM +0000, Junio C Hamano wrote:
> Pierre Habouzit <madcoder@debian.org> writes:
>
> > On Sun, Nov 25, 2007 at 10:27:09PM +0000, Junio C Hamano wrote:
> >> Pierre Habouzit <madcoder@debian.org> writes:
> >>
> >> > Hmm it doesn't because I would have to call git commit -v each time I
> >> > commit and well I _like_ having the status better. And moreover I want
> >> > the diff to go in a separated buffer too.
> >>
> >> I've never felt it a problem while editing the log message in Emacs.
> >>
> >> Don't enhanced vi implementations let you split the same buffer into
> >> two allowing you to view different portions of it these days?
> >
> > Well, maybe I could write my plugin so that it cuts the diff out from
> > the main buffer indeed, though I will have to learn using git commit -v
> > instead of git commit :P
> >
> > That and the fact that the syntax colorization of the diff doesn't
> > work, but it's probably not up to git to fix that.
>
> Or you can use pre-commit hook (which will be run with GIT_INDEX_FILE
> set to the index file used for the commit) to generate the diff in a
> separate file, and set EDITOR (or GIT_EDITOR) to a script around vim to
> open the given COMMIT_EDITMSG as well as that file you create.
*ha* _that_ sounds more like the kind of things I was lurking for.
Sounds like a plan thanks :)
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC] Making ce_path_match() more useful by accepting globs
From: Alex Riesen @ 2007-11-26 0:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7vr6ienqxr.fsf@gitster.siamese.dyndns.org>
Junio C Hamano, Sun, Nov 25, 2007 19:03:12 +0100:
> Currently ce_path_match() only uses "the leading directory" match, and
> does not understand file globs. These do not work:
>
> git diff-files 't/*.sh'
> git diff-index HEAD 'xdiff/*.c'
> git update-index -g 'Documentation/howto/*.txt'
How should my scripts handle files with "*" in names?
Maybe before the proposed change we should make all plumbing accept
"--stdin" (which does not expand globs)?
P.S. you have something broken in your mailer:
To: Linus@sceptre.sasl.smtp.pobox.com,
"Torvalds <torvalds"@linux-fundation.org
^ permalink raw reply
* Re: [RFC] best way to show diff of commit
From: Jan Hudec @ 2007-11-26 0:25 UTC (permalink / raw)
To: Pierre Habouzit, Git ML; +Cc: Kristian Høgsberg
In-Reply-To: <20071125211831.GA21121@artemis.corp>
On Sun, Nov 25, 2007 at 22:18:31 +0100, Pierre Habouzit wrote:
> Hi there,
>
> There is specific script I run in my vim with git, that tries to show
> from the 'status' git commit shows in the buffer which list of files has
> changed, and builds a diff from it quite clumsily[0].
>
> I wonder how hard it would be for git commit to "stash" the current
> commit being sent somewhere editors would be able to have a look at (an
> alternate index is probably fine). Note that maybe I'm stupid and
> overlooked that such a thing already exists. I'd like to have it in two
> flavors: normal and amend mode. normal mode would show what the
> resulting commit diff looks like, and the amend mode only shows the
> incrementall diff the amend adds to the previous commit.
Such thing does already exist. When the editor is called, the index pointed
to by GIT_INDEX_FILE (or the default index if unset) is exactly what will
be in the commit.
Hm, looking at the builtin-commit.c that is currently cooking in next, it
does not seem to be the case there. It probably should, so the editor can
inspect what will be commited.
> My question is: what do you think is the best way to do that, and
> where ?
Are you talking about the ftplugins/git.vim script from vim-scripts package,
right?
All it needs to do is call 'git diff --cached'. The below patch seems to work
here (tried commit, commit -a, commit --amend, commit -a --amend and commit
from subdirectory and they seemed to all work).
> [0] the issue with this approach is that it's completely broken in
> amending mode (does not shows the proper thing), and the generated
I didn't find any issue with amending mode (showed incremental diff for me
all right). The problem was when a file was being touched by the commit but
work tree had unstaged changes. Such changes were shown when they shouldn't.
> diffs aren't excellent, because as an editor plugin, it's hard to
> treat renames and copies easily, so I generate really really nasty
> diffs in that case too.
With --cached, detecting copies is just a matter of adding -C. In the patch
below I added only one -C, but it should probably be user-configurable to use
no, one or two (equivalent of --find-copies-harder).
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
---8<---
--- vim-scripts/ftplugin/git.vim.orig 2007-07-24 09:46:19.000000000 +0200
+++ vim-scripts/ftplugin/git.vim 2007-11-26 01:01:59.000000000 +0100
@@ -14,41 +14,6 @@
"{{{ function Git_diff_windows
function! Git_diff_windows(vertsplit, auto)
- let i = 0
- let list_of_files = ''
-
- " drop everything until '# (will commit)' and the next empty line
- while i <= line('$')
- let line = getline(i)
- if line == '# Changes to be committed:'
- let i = i + 3
- break
- endif
-
- let i = i + 1
- endwhile
-
- " read file names until we have EOF or an empty line
- while i <= line('$')
- let line = getline(i)
- if line =~ '^#\s*[a-z ]*:.*->.*$'
- let file = substitute(line, '^#[^:]*:.*->\s*\(.*\)\s*$', '\1', '')
- let list_of_files = list_of_files . ' '.file
- let file = substitute(line, '^#[^:]*:\s*\(.*\)\s*->.*$', '\1', '')
- let list_of_files = list_of_files . ' '.file
- elseif line =~ '^#\s*[a-z ]*:'
- let file = substitute(line, '^#[^:]*:\s*\(.*\)\s*$', '\1', '')
- let list_of_files = list_of_files . ' '.file
- elseif line =~ '^#\s*$'
- break
- endif
-
- let i = i + 1
- endwhile
-
- if list_of_files == ""
- return
- endif
if a:vertsplit
rightbelow vnew
@@ -56,15 +21,8 @@
rightbelow new
endif
silent! setlocal ft=diff previewwindow bufhidden=delete nobackup noswf nobuflisted nowrap buftype=nofile
- let gitDir = system('git rev-parse --git-dir 2>/dev/null')
- let gitDir = substitute(gitDir, '.git\n', '', '')
- let wd = getcwd()
- if gitDir != ''
- exe 'cd '.gitDir
- endif
- exe 'normal :r!LANG=C git diff HEAD -- ' . list_of_files . "\n1Gdd"
- exe 'normal :r!LANG=C git diff --stat HEAD -- ' . list_of_files . "\no\<esc>1GddO\<esc>"
- exe 'cd '.wd
+ exe "normal :r!LANG=C git diff --cached -C\n1Gdd"
+ exe "normal :r!LANG=C git diff --stat --cached -C\no\<esc>1GddO\<esc>"
setlocal nomodifiable
noremap <buffer> q :bw<cr>
if a:auto
^ permalink raw reply
* Re: [RFC] Making ce_path_match() more useful by accepting globs
From: Junio C Hamano @ 2007-11-26 0:30 UTC (permalink / raw)
To: Alex Riesen; +Cc: Linus Torvalds, git
In-Reply-To: <20071126001114.GA10286@steel.home>
Alex Riesen <raa.lkml@gmail.com> writes:
> Junio C Hamano, Sun, Nov 25, 2007 19:03:12 +0100:
>> Currently ce_path_match() only uses "the leading directory" match, and
>> does not understand file globs. These do not work:
>>
>> git diff-files 't/*.sh'
>> git diff-index HEAD 'xdiff/*.c'
>> git update-index -g 'Documentation/howto/*.txt'
>
> How should my scripts handle files with "*" in names?
We DO NOT CARE.
Why?
How would you handle such files from the command line session without
git? "ls such-*-a-file" will also show such-silly-a-file as well.
IOW, the user is shooting in the foot --- and at that point I am not all
that interested in helping him.
Having said that, I would think that quoting the meta from fnmatch(3)
like this:
git ls-files 'such-\*-a-file'
would work fine, just like
ls such-\*-a-file
would.
If "ls such-*-a-file" reports only one file,
git ls-files 'such-*-a-file'
would also report that file as well.
So in practice I do not see a problem.
^ permalink raw reply
* Re: [RFC] Making ce_path_match() more useful by accepting globs
From: Junio C Hamano @ 2007-11-26 0:48 UTC (permalink / raw)
To: Alex Riesen; +Cc: Linus Torvalds, git
In-Reply-To: <7vlk8lj1b7.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Alex Riesen <raa.lkml@gmail.com> writes:
>
>> Junio C Hamano, Sun, Nov 25, 2007 19:03:12 +0100:
>>> Currently ce_path_match() only uses "the leading directory" match, and
>>> does not understand file globs. These do not work:
>>>
>>> git diff-files 't/*.sh'
>>> git diff-index HEAD 'xdiff/*.c'
>>> git update-index -g 'Documentation/howto/*.txt'
>>
>> How should my scripts handle files with "*" in names?
> ...
> Having said that, I would think that quoting the meta from fnmatch(3)
> like this:
>
> git ls-files 'such-\*-a-file'
>
> would work fine, just like
>
> ls such-\*-a-file
>
> would.
Yup. I just did:
$ >M\*kefile
$ git add 'M\*kefile'
$ git ls-files 'M\*kefile'
M*kefile
$ git ls-files 'M*kefile'
M*kefile
Makefile
^ permalink raw reply
* Re: [PATCH] Add 'git fast-export', the sister of 'git fast-import'
From: Junio C Hamano @ 2007-11-26 1:16 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0711252236350.4725@wbgn129.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> diff --git a/Documentation/git-fast-export.txt b/Documentation/git-fast-export.txt
> new file mode 100644
> index 0000000..073ff7f
> --- /dev/null
> +++ b/Documentation/git-fast-export.txt
> ...
> +DESCRIPTION
> +-----------
> +This program dumps the given revisions in a form suitable to be piped
> +into gitlink:git-fast-import[1].
> +
> +You can use it as a human readable bundle replacement (see
> +gitlink:git-bundle[1]), or as a kind of an interactive
> +gitlink:git-filter-branch[1].
> +
> +
> +OPTIONS
> +-------
> +--progress=<n>::
> + Insert 'progress' statements every <n> objects, to be shown by
> + gitlink:git-fast-import[1] during import.
> +
> +--signed-tags=(ignore|warn|strip|abort)::
> + Specify how to handle signed tags. Since any transformation
> + after the export can change the tag names (which can also happen
> + when excluding revisions) the signatures will not match.
> ++
> +When asking to 'abort' (which is the default), this program will die
> +when encountering a signed tag. With 'strip', the tags will be made
> +unsigned, with 'ignore', they will be silently ignored (i.e. not exported)
> +and with 'warn', they will be exported, but you will see a warning.
I am not sure if abort should be the default.
If a straight dump-restore is made without rewriting, the result will be
identical to the original, right?
The reason I mention a straight dump-restore is because ...
> +$ git fast-export master~5..master |
> + sed "s|refs/heads/master|refs/heads/other|" |
> + git fast-import
... I find this a quite unrealistic example to assume that the data
stream does not have some string and convert blindly without parsing.
On the other hand, we _could_ also have a separate filter that works on
input stream for fast-import, but that filter should know what the
fast-import input stream looks like (a simple sed does not cut it).
So unless the future direction is to deprecate filter-branch and replace
it with such a fast-import based filter in between fast-export and
fast-import, I think the use of fast-export is to make verbatim copy
without munging the contents, which leads me to think --signed-tag
option should default to "export it as-is".
... which seem to be missing from the available values to the option.
> diff --git a/builtin-fast-export.c b/builtin-fast-export.c
> new file mode 100755
> index 0000000..48d0c54
> --- /dev/null
> +++ b/builtin-fast-export.c
> ...
> +/*
> + * TODO:
> + * - tags (--signed-tags=(ignore|warn|strip|abort)
> + */
This comment is stale?
^ permalink raw reply
* Re: If you would write git from scratch now, what would you change?
From: Steven Walter @ 2007-11-26 1:28 UTC (permalink / raw)
To: Pierre Habouzit, Jakub Narebski, git
In-Reply-To: <20071125222314.GC21121@artemis.corp>
[-- Attachment #1: Type: text/plain, Size: 1159 bytes --]
On Sun, Nov 25, 2007 at 11:23:14PM +0100, Pierre Habouzit wrote:
> On Sun, Nov 25, 2007 at 09:48:27PM +0000, Jakub Narebski wrote:
> > If you would write git from scratch now, from the beginning, without
> > concerns for backwards compatibility, what would you change, or what
> > would you want to have changed?
>
> * reset/checkout/revert. The commands to wonderful things, but this UI
> is a mess for the newcomer.
Heartily seconded. I think checkout is the most egregrious of the
three. git-checkout can be used to:
* Switch branches
* Create a branch
* Change the state of all files to a particular commit
* Change the state of a particular file to that of the index
* Change the state of a particular file (and index) to a particular
commit
To makes things more complicated, several of these tasks can be done
with other commands. Short of rewriting git from scratch, what can be
done to simplify the many-to-many mapping of tasks to commands?
--
-Steven Walter <stevenrwalter@gmail.com>
Freedom is the freedom to say that 2 + 2 = 4
B2F1 0ECC E605 7321 E818 7A65 FC81 9777 DC28 9E8F
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] add a howto document about corrupted blob recovery
From: J. Bruce Fields @ 2007-11-26 2:12 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, Linus Torvalds, git
In-Reply-To: <alpine.LFD.0.9999.0711091221210.21255@xanadu.home>
On Fri, Nov 09, 2007 at 12:28:19PM -0500, Nicolas Pitre wrote:
> Extracted from a post by Linus on the mailing list.
>
> Signed-off-by: Nicolas Pitre <nico@cam.org>
I rearranged this some more and added it to the manual, assuming that
makes sense to everyone.
I think there needs to be some discussion of pack objects and stuff too
some day. I added a few mail archive references to the "todo" section.
--b.
commit d6e199cb6ff911e8e3e39c8b7021512a14ea79a5
Author: J. Bruce Fields <bfields@citi.umich.edu>
Date: Sat Mar 3 22:53:37 2007 -0500
user-manual: recovering from corruption
Some instructions on dealing with corruption of the object database.
Most of this text is from an example by Linus, identified by Nicolas
Pitre <nico@cam.org> with a little further editing by me.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index c027353..3166fb6 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1554,6 +1554,11 @@ This may be time-consuming. Unlike most other git operations (including
git-gc when run without any options), it is not safe to prune while
other git operations are in progress in the same repository.
+If gitlink:git-fsck[1] complains about sha1 mismatches or missing
+objects, you may have a much more serious problem; your best option is
+probably restoring from backups. See
+<<recovering-from-repository-corruption>> for a detailed discussion.
+
[[recovering-lost-changes]]
Recovering lost changes
~~~~~~~~~~~~~~~~~~~~~~~
@@ -3172,6 +3177,127 @@ confusing and scary messages, but it won't actually do anything bad. In
contrast, running "git prune" while somebody is actively changing the
repository is a *BAD* idea).
+[[recovering-from-repository-corruption]]
+Recovering from repository corruption
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+By design, git treats data trusted to it with caution. However, even in
+the absence of bugs in git itself, it is still possible that hardware or
+operating system errors could corrupt data.
+
+The first defense against such problems is backups. You can back up a
+git directory using clone, or just using cp, tar, or any other backup
+mechanism.
+
+As a last resort, you can search for the corrupted objects and attempt
+to replace them by hand. Back up your repository before attempting this
+in case you corrupt things even more in the process.
+
+We'll assume that the problem is a single missing or corrupted blob,
+which is sometimes a solveable problem. (Recovering missing trees and
+especially commits is *much* harder).
+
+Before starting, verify that there is corruption, and figure out where
+it is with gitlink:git-fsck[1]; this may be time-consuming.
+
+Assume the output looks like this:
+
+------------------------------------------------
+$ git-fsck --full
+broken link from tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8
+ to blob 4b9458b3786228369c63936db65827de3cc06200
+missing blob 4b9458b3786228369c63936db65827de3cc06200
+------------------------------------------------
+
+(Typically there will be some "dangling object" messages too, but they
+aren't interesting.)
+
+Now you know that blob 4b9458b3 is missing, and that the tree 2d9263c6
+points to it. If you could find just one copy of that missing blob
+object, possibly in some other repository, you could move it into
+.git/objects/4b/9458b3... and be done. Suppose you can't. You can
+still examine the tree that pointed to it with gitlink:git-ls-tree[1],
+which might output something like:
+
+------------------------------------------------
+$ git ls-tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8
+100644 blob 8d14531846b95bfa3564b58ccfb7913a034323b8 .gitignore
+100644 blob ebf9bf84da0aab5ed944264a5db2a65fe3a3e883 .mailmap
+100644 blob ca442d313d86dc67e0a2e5d584b465bd382cbf5c COPYING
+...
+100644 blob 4b9458b3786228369c63936db65827de3cc06200 myfile
+...
+------------------------------------------------
+
+So now you know that the missing blob was the data for a file named
+"myfile". And chances are you can also identify the directory--let's
+say it's in "somedirectory". If you're lucky the missing copy might be
+the same as the copy you have checked out in your working tree at
+"somedirectory/myfile"; you can test whether that's right with
+gitlink:git-hash-object[1]:
+
+------------------------------------------------
+$ git hash-object -w somedirectory/myfile
+------------------------------------------------
+
+which will create and store a blob object with the contents of
+somedirectory/myfile, and output the sha1 of that object. if you're
+extremely lucky it might be 4b9458b3786228369c63936db65827de3cc06200, in
+which case you've guessed right, and the corruption is fixed!
+
+Otherwise, you need more information. How do you tell which version of
+the file has been lost?
+
+The easiest way to do this is with:
+
+------------------------------------------------
+$ git log --raw --all --full-history -- somedirectory/myfile
+------------------------------------------------
+
+Because you're asking for raw output, you'll now get something like
+
+------------------------------------------------
+commit abc
+Author:
+Date:
+...
+:100644 100644 4b9458b... newsha... M somedirectory/myfile
+
+
+commit xyz
+Author:
+Date:
+
+...
+:100644 100644 oldsha... 4b9458b... M somedirectory/myfile
+------------------------------------------------
+
+This tells you that the immediately preceding version of the file was
+"newsha", and that the immediately following version was "oldsha".
+You also know the commit messages that went with the change from oldsha
+to 4b9458b and with the change from 4b9458b to newsha.
+
+If you've been committing small enough changes, you may now have a good
+shot at reconstructing the contents of the in-between state 4b9458b.
+
+If you can do that, you can now recreate the missing object with
+
+------------------------------------------------
+$ git hash-object -w <recreated-file>
+------------------------------------------------
+
+and your repository is good again!
+
+(Btw, you could have ignored the fsck, and started with doing a
+
+------------------------------------------------
+$ git log --raw --all
+------------------------------------------------
+
+and just looked for the sha of the missing object (4b9458b..) in that
+whole thing. It's up to you - git does *have* a lot of information, it is
+just missing one particular blob version.
+
[[the-index]]
The index
-----------
@@ -4381,4 +4507,7 @@ Write a chapter on using plumbing and writing scripts.
Alternates, clone -reference, etc.
-git unpack-objects -r for recovery
+More on recovery from repository corruption. See:
+ http://marc.theaimsgroup.com/?l=git&m=117263864820799&w=2
+ http://marc.theaimsgroup.com/?l=git&m=117147855503798&w=2
+ http://marc.theaimsgroup.com/?l=git&m=117147855503798&w=2
^ permalink raw reply related
* patches
From: J. Bruce Fields @ 2007-11-26 2:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
There's some more user-manual stuff in the git repository at
ssh://linux-nfs.org/~bfields/exports/git.git maint
J. Bruce Fields (4):
user-manual: define "branch" and "working tree" at start
user-manual: failed push to public repository
user-manual: clarify language about "modifying" old commits
user-manual: recovering from corruption
Documentation/user-manual.txt | 225 ++++++++++++++++++++++++++++++++++++-----
1 files changed, 201 insertions(+), 24 deletions(-)
--b.
commit 1cdade2c4cb27f648a98d326ef3db523b6afafa7
Author: J. Bruce Fields <bfields@citi.umich.edu>
Date: Sat Mar 3 22:53:37 2007 -0500
user-manual: recovering from corruption
Some instructions on dealing with corruption of the object database.
Most of this text is from an example by Linus, identified by Nicolas
Pitre <nico@cam.org> with a little further editing by me.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
commit 7cb192eab0251911e2ca77d4ecceb621dd2d34f5
Author: J. Bruce Fields <bfields@citi.umich.edu>
Date: Sun Nov 25 19:01:57 2007 -0500
user-manual: clarify language about "modifying" old commits
It's important to remember that git doesn't really allowing "editing" or
"modifying" commits, only replacing them by new commits. Redo some of
the language to make this clearer.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
commit 81eb417ad423ef7e8d088d517f89d3bda92f9c06
Author: J. Bruce Fields <bfields@citi.umich.edu>
Date: Sun Nov 25 17:54:19 2007 -0500
user-manual: failed push to public repository
More details on the case of a failed push to a public (non-shared)
repository.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
commit 0c4a33b54f3dbb9fa8cd2f5cf0e2a6363849d899
Author: J. Bruce Fields <bfields@citi.umich.edu>
Date: Sun Nov 25 13:53:37 2007 -0500
user-manual: define "branch" and "working tree" at start
Some explanation here might help.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
^ permalink raw reply
* Re: [Resend Trivial PATCH] Print the real filename whose opening failed.
From: Junio C Hamano @ 2007-11-26 3:15 UTC (permalink / raw)
To: André Goddard Rosa; +Cc: Git Mailing List
In-Reply-To: <b8bf37780711251338p500797e7h3633dd3189311101@mail.gmail.com>
Thanks, will apply.
^ permalink raw reply
* Re: [PATCH] Use is_absolute_path() in diff-lib.c, lockfile.c, setup.c, trace.c
From: Junio C Hamano @ 2007-11-26 3:54 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <11960297431954-git-send-email-prohaska@zib.de>
Steffen Prohaska <prohaska@zib.de> writes:
> Using the helper function to test for absolute paths makes porting easier.
These probably make sense. I obviously do not see any downside from the
POSIX side, and can imagine that treating "C:\" prefix as "absolute
paths" at these four places will not have any ill effect on the Windows
side (IOW, the codepaths that follow these four places seem to do a
sensible thing even if the "absolute path" prefix is not a single '/',
but would work fine as-is).
I am a bit surprised that there are only four places you needed to
touch, though.
> BTW, what happend to the msysgit related patches:
>
> [PATCH 1/3] sha1_file.c: Fix size_t related printf format warnings
> [PATCH 2/3] builtin-init-db: use get_git_dir() instead of getenv()
>
> I never received comments about them, nor do I find them on pu.
Lack of comments was probably due to mixture of bad timing and general
lack of interests. Many people are busy working on their turkeys than
hacking this time of the year ;-)
I am reluctant to queue msysgit/gitwin related patches without seeing
positive comments from other people involved on the Windows side, unless
they are trivial and obvious improvements.
* [1/3] seems without harm but on the other hand does not seem so
urgent either.
* [2/3] may introduce chicken-and-egg problem (use of get_git_dir()
inside git-init feels quite iffy, as it calls setup_git_env(), which
does repository discovery), without an obvious and clear advantage.
For these reasons, both of them disqualify from being trivial and
obvious improvements, so I did not pick them up unilaterally before
seeing positive comments from other people.
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Nicolas Pitre @ 2007-11-26 4:02 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Junio C Hamano, Jeff King, Johannes Schindelin, git
In-Reply-To: <20071125215128.GC23820@fieldses.org>
On Sun, 25 Nov 2007, J. Bruce Fields wrote:
> There's a very brief mention of this:
>
> "As with git-fetch, git-push will complain if this does not
> result in a <<fast-forwards,fast forward>>. Normally this is a
> sign of something wrong. However, if you are sure you know what
> you're doing, you may force git-push to perform the update
> anyway by preceding the branch name by a plus sign:
... or use "git push -f" (is it mentioned in the manual?)
> But it'd probably be better to have a separate section. That makes it
> possible to say a little more, and also gets a section called "what to
> do when a push fails" into the table of contents.
>
> (Though that's a little vague--push can also fail just because you
> mispell the url or something. A more precise reference to the
> particular error might be better, but we'll have to agree on the error
> message first....)
>
> Anyway, here's a first draft.
I think we should devote a section of the manual to the "rebase"
workflow compared to the "merge" workflow. One of the public Git repo
I currently maintain is constantly rebased, and I've provided a quick
Git update cheat sheet along with its announcement for that case:
http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2007-November/043147.html
I also wrote an introductory document for $job internal use. I have a
section where I briefly cover the main differences and implications for
merge vs rebase. Here it is -- please feel free to add it to the manual
if you think it can be valuable.
----- >8
Rebase vs Merge
---------------
Merge and rebase may look like they are doing the same thing, but they act
very differently on the repository. Merging basically takes all the
changes in the remote branch and mix them with your local branch.
For example, if you create a branch "mywork" from the orion/core branch,
you will end up with something that looks like this:
a--b--c <-- orion/master
\
A--B--C <-- mywork
After a fetch, the remote branch might have advanced in parallel to
local changes as follows:
a--b--c--d--e--f <-- orion/master
\
A--B--C <-- mywork
If you later do a 'git merge orion/master', your history will look like
this, where 'M' is a merge commit:
a--b--c--d--e--f <-- orion/master
\ \
A--B--C--M <-- mywork
A rebase, on the other hand, takes all your changes and reapplies them to
the current state of the specified branch, and assign the result to the
currently checked out branch. With the same example, if you were to do a
'git rebase orion/master', you would get something like this:
a--b--c--d--e--f <-- orion/master
\
A'--B'--C' <-- mywork
Rebase does what the name implies and creates a new baseline for your
branch. The benefit of this is that you end up with a cleaner history log,
especially if you have to update with the remote branch often, in both
your repository and in upstream repositories that gets updated from you.
Tracking a rebased remote branch
--------------------------------
Let's suppose that the remote branch you're tracking is itself subject
to be rebased. Before performing a fetch to update that remote branch,
your history might look like the previous example:
a--b--c--d--e--f <-- orion/master
\
A'--B'--C' <-- mywork
If the remote branch had some commit replaced, or was rebased on a
different commit (or both), then things could look like this after a
fetch:
a---b---c'--d'--e'--f'--g <-- orion/master
\
c---d---e---f <-- orion/master@{1}
\
A---B---C <-- mywork
In this example, commits c, d, e and f are not present anymore in the
remote repository. They are still reachable from your "mywork" local
branch though. The "orion/master@{1}" is the notation used to refer to the
previous value (before the fetch) of "orion/master".
If you were to use 'git merge' to bring the new commits (c', d', e', f'
and g) into your local branch, that wouldn't get rid of the commits that
they are meant to replace, and is likely to cause a major merge conflict.
The only option in that case is to rebase your work. Yet there is a twist
because 'rebase' moves every commit reachable from the current branch on
top of the specified branch by default, including those c-d-e-f commits.
So the --onto argument to 'git rebase' must be used to skip over those
unwanted commits as follows:
git rebase --onto orion/master orion/master@{1} mywork
This means to rebase commits between orion/master@{1} and mywork on top of
orion/master and assing mywork to the result. The git-rebase man page
provides more examples and a detailed explanation of how 'rebase' works
which is worth a read.
NOte: the orion Git repository is indeed rebased often. So you'll have
to use this rebase invokation when fetching updates from it.
^ permalink raw reply
* Re: [PATCH] builtin-add: fix command line building to call interactive
From: Jeff King @ 2007-11-26 4:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Wincent Colaiuta, git
In-Reply-To: <7vprxyksxf.fsf@gitster.siamese.dyndns.org>
On Sun, Nov 25, 2007 at 11:48:28AM -0800, Junio C Hamano wrote:
> > git-add -i *.h
> >
> > (Note that's "*.h" and not "\*.h"). In the Git repository, without
> > validation, this just works. With strict validation, it would complain...
>
> I'd mostly agree, but we need to realize that this is a two edged sword.
> Pathspecs can be leading-directories or fileglobs. For fileglobs, you
> are right. The user can let the shell do the globbing. Not validating,
> however, also means that
>
> git add -p Documentatoin
>
> would report "there is nothing to patch" without being helpful, pointing
> out that the name of the directory is misspelled.
I think the problem there is not validation, but that the previous
proposal was validating the wrong thing. IOW, the user doesn't want a
complaint "this file is not tracked by git" (which catches untracked
things with *.h) but rather "this file does not even exist" (which
catches typos like Documentatoin).
So it is not really a git pathspec being provided (from the user's point
of view), but rather something else (a pathspec _or_ a working tree
file).
-Peff
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: J. Bruce Fields @ 2007-11-26 4:15 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, Jeff King, Johannes Schindelin, git
In-Reply-To: <alpine.LFD.0.99999.0711252029020.9605@xanadu.home>
On Sun, Nov 25, 2007 at 11:02:05PM -0500, Nicolas Pitre wrote:
> On Sun, 25 Nov 2007, J. Bruce Fields wrote:
>
> > There's a very brief mention of this:
> >
> > "As with git-fetch, git-push will complain if this does not
> > result in a <<fast-forwards,fast forward>>. Normally this is a
> > sign of something wrong. However, if you are sure you know what
> > you're doing, you may force git-push to perform the update
> > anyway by preceding the branch name by a plus sign:
>
> ... or use "git push -f" (is it mentioned in the manual?)
>
> > But it'd probably be better to have a separate section. That makes it
> > possible to say a little more, and also gets a section called "what to
> > do when a push fails" into the table of contents.
> >
> > (Though that's a little vague--push can also fail just because you
> > mispell the url or something. A more precise reference to the
> > particular error might be better, but we'll have to agree on the error
> > message first....)
> >
> > Anyway, here's a first draft.
>
> I think we should devote a section of the manual to the "rebase"
> workflow compared to the "merge" workflow.
There's this:
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#using-git-rebase
It doesn't explicitly compare the two, but I think between that and the
containing chapter, it hits on the main issues.
> One of the public Git repo
> I currently maintain is constantly rebased, and I've provided a quick
> Git update cheat sheet along with its announcement for that case:
>
> http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2007-November/043147.html
The trick of
tag -d old_base remote/master
git fetch remote
git rebase --onto remote/master old_base my_work
is something we don't document anywhere.
(We might not have to quite so much if we came up with a command that
did the job of git-rebase and/or cherry-pick with more intuitive
syntax....)
> I also wrote an introductory document for $job internal use. I have a
> section where I briefly cover the main differences and implications for
> merge vs rebase. Here it is -- please feel free to add it to the manual
> if you think it can be valuable.
Thanks. I think the manual covers most of what's in the "rebase vs
merge" section already. (Though it'd be worth reconsidering how we do
it.)
The "tracking a rebased remote branch" stuff would be new and, I think,
helpful.
I'll take a closer look at it eventually--but if someone wants to speed
the process by working out exactly where to fit this in, which parts are
duplicated, etc., and turn the result into a patch, I'd be happy.
I do find that trying to work on top of a constantly rebased branch is
annoying no matter how I do it. So I sometimes wonder if we shouldn't
instead be finding ways to avoid the practice.
--b.
>
> ----- >8
>
> Rebase vs Merge
> ---------------
>
> Merge and rebase may look like they are doing the same thing, but they act
> very differently on the repository. Merging basically takes all the
> changes in the remote branch and mix them with your local branch.
> For example, if you create a branch "mywork" from the orion/core branch,
> you will end up with something that looks like this:
>
> a--b--c <-- orion/master
> \
> A--B--C <-- mywork
>
> After a fetch, the remote branch might have advanced in parallel to
> local changes as follows:
>
> a--b--c--d--e--f <-- orion/master
> \
> A--B--C <-- mywork
>
> If you later do a 'git merge orion/master', your history will look like
> this, where 'M' is a merge commit:
>
> a--b--c--d--e--f <-- orion/master
> \ \
> A--B--C--M <-- mywork
>
> A rebase, on the other hand, takes all your changes and reapplies them to
> the current state of the specified branch, and assign the result to the
> currently checked out branch. With the same example, if you were to do a
> 'git rebase orion/master', you would get something like this:
>
> a--b--c--d--e--f <-- orion/master
> \
> A'--B'--C' <-- mywork
>
> Rebase does what the name implies and creates a new baseline for your
> branch. The benefit of this is that you end up with a cleaner history log,
> especially if you have to update with the remote branch often, in both
> your repository and in upstream repositories that gets updated from you.
>
>
> Tracking a rebased remote branch
> --------------------------------
>
> Let's suppose that the remote branch you're tracking is itself subject
> to be rebased. Before performing a fetch to update that remote branch,
> your history might look like the previous example:
>
> a--b--c--d--e--f <-- orion/master
> \
> A'--B'--C' <-- mywork
>
> If the remote branch had some commit replaced, or was rebased on a
> different commit (or both), then things could look like this after a
> fetch:
>
> a---b---c'--d'--e'--f'--g <-- orion/master
> \
> c---d---e---f <-- orion/master@{1}
> \
> A---B---C <-- mywork
>
> In this example, commits c, d, e and f are not present anymore in the
> remote repository. They are still reachable from your "mywork" local
> branch though. The "orion/master@{1}" is the notation used to refer to the
> previous value (before the fetch) of "orion/master".
>
> If you were to use 'git merge' to bring the new commits (c', d', e', f'
> and g) into your local branch, that wouldn't get rid of the commits that
> they are meant to replace, and is likely to cause a major merge conflict.
>
> The only option in that case is to rebase your work. Yet there is a twist
> because 'rebase' moves every commit reachable from the current branch on
> top of the specified branch by default, including those c-d-e-f commits.
> So the --onto argument to 'git rebase' must be used to skip over those
> unwanted commits as follows:
>
> git rebase --onto orion/master orion/master@{1} mywork
>
> This means to rebase commits between orion/master@{1} and mywork on top of
> orion/master and assing mywork to the result. The git-rebase man page
> provides more examples and a detailed explanation of how 'rebase' works
> which is worth a read.
>
> NOte: the orion Git repository is indeed rebased often. So you'll have
> to use this rebase invokation when fetching updates from it.
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Nicolas Pitre @ 2007-11-26 4:29 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Junio C Hamano, Jeff King, Johannes Schindelin, git
In-Reply-To: <20071126041521.GA21120@fieldses.org>
On Mon, 26 Nov 2007, J. Bruce Fields wrote:
> I do find that trying to work on top of a constantly rebased branch is
> annoying no matter how I do it. So I sometimes wonder if we shouldn't
> instead be finding ways to avoid the practice.
I don't think it can't be avoided in many cases. Some stuff gets
rebased because it has to be refined before it is merged in a more
stable and more "official" repository. Working on top of a rebased
branch could be much easier if there was a dedicated command to perform
the local rebase of one's work after a fetch, just like the pull command
does a merge after a fetch, at which point both work flows would be
almost equivalent wrt ease of use.
Nicolas
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: J. Bruce Fields @ 2007-11-26 4:45 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, Jeff King, Johannes Schindelin, git
In-Reply-To: <alpine.LFD.0.99999.0711252324360.9605@xanadu.home>
On Sun, Nov 25, 2007 at 11:29:56PM -0500, Nicolas Pitre wrote:
> On Mon, 26 Nov 2007, J. Bruce Fields wrote:
>
> > I do find that trying to work on top of a constantly rebased branch is
> > annoying no matter how I do it. So I sometimes wonder if we shouldn't
> > instead be finding ways to avoid the practice.
>
> I don't think it can't be avoided in many cases. Some stuff gets
> rebased because it has to be refined before it is merged in a more
> stable and more "official" repository.
Well, there is for example the option of doing things like:
git checkout -b new-mywork mywork
git fetch origin
git rebase new-mywork origin
# further reordering of commits, etc., as needed
git merge -s ours mywork
git branch -d mywork
git push mypubrepo new-mywork:mywork
and if you do this each time, then the public branch named "mywork"
always fast-forwards. Its first parent, mywork^, is always a clean
patch series against upstream, and is what you'll eventually submit.
The second parent leads to historical versions of the patch series.
> Working on top of a rebased
> branch could be much easier if there was a dedicated command to perform
> the local rebase of one's work after a fetch, just like the pull command
> does a merge after a fetch, at which point both work flows would be
> almost equivalent wrt ease of use.
I don't think that works if you have more than one branch built on top
of the branch you're fetching.
The problem is that you have to do the rebase at the same time as the
fetch, because it's only the fetch that knows what the old head of the
branch was.
You don't need to know what the old head of the branch was before if
you're fetching a branch that always fast-forwards. But you do in the
case where it doesn't fast-forward, because in that case the old head
will be forgotten as soon as you're done.
--b.
^ permalink raw reply
* Re: [PATCH] "git-tag -s" should create a signed annotated tag
From: Jeff King @ 2007-11-26 4:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Carlos Rica
In-Reply-To: <7vprxxj4hl.fsf@gitster.siamese.dyndns.org>
On Sun, Nov 25, 2007 at 03:21:42PM -0800, Junio C Hamano wrote:
> * It's _very_ disturbing that the testsuite did not catch this
> breakage, even though I though we had a very detailed coverage for
> "git tag" when it was rewritten in C.
Then where is the new test to accompany your patch? :P
-- >8 --
git-tag: test that -s implies an annotated tag
This detects a regression introduced while moving git-tag to a C
builtin.
Signed-off-by: Jeff King <peff@peff.net>
---
t/t7004-tag.sh | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/t/t7004-tag.sh b/t/t7004-tag.sh
index 736f22e..c7130c4 100755
--- a/t/t7004-tag.sh
+++ b/t/t7004-tag.sh
@@ -667,6 +667,22 @@ test_expect_success 'creating a signed tag with -F - should succeed' '
git diff expect actual
'
+cat >fakeeditor <<'EOF'
+#!/bin/sh
+test -n "$1" && exec >"$1"
+echo A signed tag message
+echo from a fake editor.
+EOF
+chmod +x fakeeditor
+get_tag_header implied-annotate $commit commit $time >expect
+./fakeeditor >>expect
+echo '-----BEGIN PGP SIGNATURE-----' >>expect
+test_expect_success '-s implies annotated tag' '
+ GIT_EDITOR=./fakeeditor git-tag -s implied-annotate &&
+ get_tag_msg implied-annotate >actual &&
+ git diff expect actual
+'
+
test_expect_success \
'trying to create a signed tag with non-existing -F file should fail' '
! test -f nonexistingfile &&
--
1.5.3.6.2022.gd7807a-dirty
^ permalink raw reply related
* Re: [PATCH] "git-tag -s" should create a signed annotated tag
From: Carlos Rica @ 2007-11-26 4:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vprxxj4hl.fsf@gitster.siamese.dyndns.org>
On Nov 26, 2007 12:21 AM, Junio C Hamano <gitster@pobox.com> wrote:
> The earlier patch 396865859918e9c7bf8ce74aae137c57da134610 (Make
> builtin-tag.c use parse_options.) broke "git-tag -s".
>
> * It's _very_ disturbing that the testsuite did not catch this
> breakage, even though I though we had a very detailed coverage for
> "git tag" when it was rewritten in C.
Yes, you're right, "-s" without -m or -F is creating lightweight tags
in my proposal.
I think it is due to the absence of tests checking the "editor" option, that is,
calls without -m or -F options to provide the message, since the tests are using
only those and they are enabling automatically the creation of annotated tags.
I need to think in adding tests replacing the editor with a custom command
to check also the correct behaviour of git-tag when the EDITOR and/or
the other variables are set.
At the end, I've learned that it's better to test a little of every feature than
test completely only a few of them.
Thank you.
^ permalink raw reply
* Re: If you would write git from scratch now, what would you change?
From: Junio C Hamano @ 2007-11-26 6:11 UTC (permalink / raw)
To: Steven Walter; +Cc: Pierre Habouzit, Jakub Narebski, git
In-Reply-To: <20071126012837.GA5402@dervierte>
Steven Walter <stevenrwalter@gmail.com> writes:
> Heartily seconded. I think checkout is the most egregrious of the
> three. git-checkout can be used to:
>
> * Switch branches
> * Create a branch
> * Change the state of all files to a particular commit
> * Change the state of a particular file to that of the index
> * Change the state of a particular file (and index) to a particular
> commit
Come on. The second one is just to give a short-hand side-effet for
commonly used operation and you do not have to use it nor learn it.
Also, you have written the last three in a more confusing way than it is
necessary. They are all the same thing but with variations --- your way
of writing them is like enumerating "change the state of files whose
name starts with A", "change the state of files whose name starts with
B", etc. as if they are distinctly different and confusing operations.
Let's clear the confusion. Although it is not bad like the above
"random 5 different operations", checkout does serve 2 quite different
purposes:
(1) checkout a revision.
This primarily affects the notion of where your HEAD is. Is it
pointing at a branch, or detached at a particular commit? In
either case, the objective from the user's point of view here is "I
want to change on which commit and/or branch I'd build the next
commit, if I were to issue git-commit command".
"I started modifying but realized that I wanted to build not on top
of master but a separate topic", is a typical use case, and this
form will let you take your local changes with you exactly for this
reason.
Obviously when people say "I checkout this commit", they mean the
state of the work tree and they mean the whole tree. It is
hopefully clear that is what you are doing from the fact that you
do not give any pathspec to the command to trigger this mode of
operation.
(2) checkout selected paths out of a commit (or the index).
"I screwed up. I want to start over modifications to these files
from the state of the previous commit (or the last state I
staged)." is a typical use case for this mode. For this reason,
the named paths are updated in the work tree and the work tree and
the index are made to match.
Again, it hopefully is clear enough that you need to give some
pathspec to it for the operation to make sense, if you understand
the purpose of the command. Like "." to mean the whole tree, "*.c"
to mean all C files, or "directory/" to mean everything underneath
it.
So yes, it does two quite different things, and that's mostly because
the verb "to check out" has overloaded meanings.
Hopefully it is clear which one you are using by thinking about the
reason WHY you are "checking out", and by looking at the way you form
the command line.
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Jan Hudec @ 2007-11-26 6:15 UTC (permalink / raw)
To: J. Bruce Fields
Cc: Nicolas Pitre, Junio C Hamano, Jeff King, Johannes Schindelin,
git
In-Reply-To: <20071126041521.GA21120@fieldses.org>
On Mon, Nov 26, 2007 at 04:15:21 +0000, J. Bruce Fields wrote:
> The trick of
>
> tag -d old_base remote/master
> git fetch remote
> git rebase --onto remote/master old_base my_work
>
> is something we don't document anywhere.
Do we really need the tag/branch?
git fetch remote
git rebase --onto remote/master remote/master@{1} my_work
And of course the thing is only needed if master has been rewound. Otherwise
just:
git rebase remote/master my_work
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
^ permalink raw reply
* Re: If you would write git from scratch now, what would you change?
From: Adam Roben @ 2007-11-26 6:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Steven Walter, Pierre Habouzit, Jakub Narebski, git
In-Reply-To: <7vejedh6xl.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Steven Walter <stevenrwalter@gmail.com> writes:
>
>> Heartily seconded. I think checkout is the most egregrious of the
>> three. git-checkout can be used to:
>>
>> * Switch branches
>> * Create a branch
>> * Change the state of all files to a particular commit
>> * Change the state of a particular file to that of the index
>> * Change the state of a particular file (and index) to a particular
>> commit
>>
>
> Come on. The second one is just to give a short-hand side-effet for
> commonly used operation and you do not have to use it nor learn it.
>
I think the overwhelming majority of git users learn `git checkout -b`.
The cases where you do want to switch to a branch you just created seem
far more common than the cases where you don't (particularly for new
users), which is the whole reason the -b option exists in the first
place. So I don't think it's reasonable to say "you can choose not to be
confused by ignoring this incredibly useful command."
> Let's clear the confusion. Although it is not bad like the above
> "random 5 different operations", checkout does serve 2 quite different
> purposes:
>
> (1) checkout a revision.
> (2) checkout selected paths out of a commit (or the index).
>
Given the above, I'd argue that it serves 3 purposes:
(1) check out a revision
(2) check out selected paths out of a commit (or the index)
(3) start working on a new branch
It's true that (1) and (3) are very closely related, but I think in the
minds of many git users (particularly new ones) they are distinct. (2)
really seems the most out of place here, and has the most potential for
finding a new home (perhaps within git-reset).
-Adam
^ 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