* [PATCH] git-commit: Reformat log messages provided on commandline
From: Petr Baudis @ 2007-05-09 14:24 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Matthieu Moy, git
In-Reply-To: <Pine.LNX.4.64.0705091513360.4167@racer.site>
Hi,
On Wed, May 09, 2007 at 03:57:28PM CEST, Johannes Schindelin wrote:
> Another reason is that you can see how the end result will look like in an
> editor. For example, you'll have a hard time making sure in the
> command line that the lines are no longer than 76 characters.
oh, indeed - good point. cg-commit uses fmt to format the message, I
think git-commit should do the same; let's see how controversial such a
change would be.
---
This makes git-commit filter log messages provided on commandline by fmt,
thus making nice paragraphs from them. This makes it possible to specify
even long commit messages on command line without worrying about this, akin
to cg-commit.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
git-commit.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-commit.sh b/git-commit.sh
index f28fc24..28cbb55 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -432,7 +432,7 @@ fi
if test "$log_message" != ''
then
- echo "$log_message"
+ echo "$log_message" | fmt
elif test "$logfile" != ""
then
if test "$logfile" = -
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Ever try. Ever fail. No matter. // Try again. Fail again. Fail better.
-- Samuel Beckett
^ permalink raw reply related
* Re: [PATCH] git-commit: Reformat log messages provided on commandline
From: Matthieu Moy @ 2007-05-09 14:59 UTC (permalink / raw)
To: git
In-Reply-To: <20070509142426.GV4489@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> - echo "$log_message"
> + echo "$log_message" | fmt
I wouldn't do that for the first line of the message.
Someone typing
$ git commit -m "a very very very very very very very very very very very very long summary" \
-m "a longer description of the above summary"
Probably doesn't want his first line to be broken (otherwise,
git-format-patch and other tools would be confused).
So, that would be more like
echo "$log_message" | (read first_line; echo "$first_line"; fmt)
Perhaps another option would be to provide, say, a -M option, doing
log_message="$log_message
$(echo $1 | fmt)"
to allow people to explicitely say whether they want reformatting. But
that's probably overkill.
--
Matthieu
^ permalink raw reply
* Re: [PATCH] git-commit: Reformat log messages provided on commandline
From: Johannes Schindelin @ 2007-05-09 15:01 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, Matthieu Moy, git
In-Reply-To: <20070509142426.GV4489@pasky.or.cz>
Hi,
On Wed, 9 May 2007, Petr Baudis wrote:
> On Wed, May 09, 2007 at 03:57:28PM CEST, Johannes Schindelin wrote:
> > Another reason is that you can see how the end result will look like in an
> > editor. For example, you'll have a hard time making sure in the
> > command line that the lines are no longer than 76 characters.
>
> oh, indeed - good point. cg-commit uses fmt to format the message, I
> think git-commit should do the same;
FWIW, I have a builtin git-fmt in my local repo, which uses the (slightly
enhanced) functions in utf8.c... Maybe after 1.5.2 I dare to submit
this...
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-commit: Reformat log messages provided on commandline
From: Petr Baudis @ 2007-05-09 15:11 UTC (permalink / raw)
To: git
In-Reply-To: <vpqps5ajb60.fsf@bauges.imag.fr>
On Wed, May 09, 2007 at 04:59:03PM CEST, Matthieu Moy wrote:
> Petr Baudis <pasky@suse.cz> writes:
>
> > - echo "$log_message"
> > + echo "$log_message" | fmt
>
> I wouldn't do that for the first line of the message.
>
> Someone typing
>
> $ git commit -m "a very very very very very very very very very very very very long summary" \
> -m "a longer description of the above summary"
>
> Probably doesn't want his first line to be broken (otherwise,
> git-format-patch and other tools would be confused).
>
> So, that would be more like
>
> echo "$log_message" | (read first_line; echo "$first_line"; fmt)
Hmm, I don't really know if it's more evil to split an extra-long line
to two or keep it longer than the maximum sane width. Since I'm torn,
I'd prefer to go for the version that's simpler (also, avoids weird
results for those who for some reason chose not to follow the usual
convention, but that's a minor point).
I don't really care, but if noone else does either, I'd stay with the
current simple version. :)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Ever try. Ever fail. No matter. // Try again. Fail again. Fail better.
-- Samuel Beckett
^ permalink raw reply
* Re: [PATCH] Git.pm: config_boolean() -> config_bool()
From: Petr Baudis @ 2007-05-09 15:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20070509104941.GK4489@pasky.or.cz>
On Wed, May 09, 2007 at 12:49:41PM CEST, Petr Baudis wrote:
> @@ -526,14 +528,16 @@ This currently wraps command('config') so it is not so fast.
>
> =cut
>
> -sub config_boolean {
> +sub config_bool {
> my ($self, $var) = @_;
> $self->repo_path()
> or throw Error::Simple("not a repository");
>
> try {
> - return $self->command_oneline('config', '--bool', '--get',
> - $var);
> + my $val = $self->command_oneline('config', '--bool', '--get',
> + $val);
^^^
Sorry, should be $var. Looks like I forgot to make install or something
when "testing" the patch, also judging by the error messages repo.or.cz
spewed furiously in the last update round.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Ever try. Ever fail. No matter. // Try again. Fail again. Fail better.
-- Samuel Beckett
^ permalink raw reply
* Re: [PATCH] Add --no-reuse-delta option to git-gc
From: Junio C Hamano @ 2007-05-09 15:15 UTC (permalink / raw)
To: Steven Grimm; +Cc: Daniel Barkalow, Theodore Ts'o, Git Mailing List
In-Reply-To: <46418E24.9020309@midwinter.com>
Steven Grimm <koreth@midwinter.com> writes:
> -Steve (who suspects this is a "yes, we talked this over early in
> git's history" question, but what the heck)
AFAICR, the answer is "heck, we have never bothered about such
low level implementation details as gzip has been good enough
for us. If you feel so inclined, go wild."
^ permalink raw reply
* Re: [PATCH] git-update-ref: add --no-deref option for overwriting/detaching ref
From: Junio C Hamano @ 2007-05-09 15:22 UTC (permalink / raw)
To: skimo; +Cc: git
In-Reply-To: <20070509103320.GA7257MdfPADPa@greensroom.kotnet.org>
Sven Verdoolaege <skimo@kotnet.org> writes:
> git-checkout is also adapted to make use of this new option
> instead of the handcrafted command sequence.
>
> Signed-off-by: Sven Verdoolaege <skimo@kotnet.org>
> ---
> All tests pass, except the recently added cvsserver tests,
> but they fail without this patch too.
Can you retry after installing libdbi and libdbd-sqlite-perl?
^ permalink raw reply
* Re: [PATCH] Git.pm: config_boolean() -> config_bool()
From: Junio C Hamano @ 2007-05-09 15:24 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20070509104941.GK4489@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> So, I realized that I'm not sure again how to stick a mail reply and new
> patch version in the same mail - originally I wanted to reply to this
> mail and send the patch as another reply, but that seemed wasteful. Now
> it seems that the only option is to stuff the mail reply in the diffstat
> area, but I refuse to do that since that's just plainly stupid.
That's your opinion to go against a convention, which is fine,
as long as you use something other than what begins with three
dashes here as a separator.
> ---
>
> This patch renames config_boolean() to config_bool() for consistency with
> the commandline interface and because it is shorter but still obvious. ;-)
> It also changes the return value from some obscure string to real Perl
> boolean, allowing for clean user code.
>
> Signed-off-by: Petr Baudis <pasky@suse.cz>
> ---
>
> git-remote.perl | 4 ++--
> git-send-email.perl | 4 ++--
> perl/Git.pm | 14 +++++++++-----
> 3 files changed, 13 insertions(+), 9 deletions(-)
>
> diff --git a/git-remote.perl b/git-remote.perl
> index 52013fe..5763799 100755
> --- a/git-remote.perl
> +++ b/git-remote.perl
> @@ -297,9 +297,9 @@ sub update_remote {
^ permalink raw reply
* Re: [PATCH v2] Custom compression levels for objects and packs
From: Nicolas Pitre @ 2007-05-09 15:27 UTC (permalink / raw)
To: Dana How; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <56b7f5510705090221g38ab0973x8631dacc601abb16@mail.gmail.com>
On Wed, 9 May 2007, Dana How wrote:
> OK, I got really confused here, so I looked over the code,
> and figured out 2 causes for my confusion.
> (1) core.legacyheaders controls use_legacy_headers, which defaults to 1.
> So currently all loose objects are in legacy format and the code block
> I spoke of doesn't trigger [without a config setting]. I didn't realize
> legacy headers were still being produced (mislead by the name!).
> (2) I read your "setting core.legacyheaders" as followed by TRUE,
> but you meant FALSE, which is not the default.
>
> I also read that 1 year after 1.4.2, the default for core.legacyheaders is
> going
> to change to FALSE. I think our discussion should assume this has
> happened.
<tangential comment>
Now that we encourage and actively preserve objects in a packed form
more agressively than we did at the time core.legacyheaders was
introduced, I really wonder if this option is still worth it. Because
the packing of loose objects has to go through the delta match loop
anyway, and since most of them should end up being deltified in most
cases, there is really little advantage to have this parallel loose
object format as the CPU savings it might provide is rather lost in the
noise in the end.
So I suggest that we get rid of core.legacyheaders, preserve the legacy
format as the only writable loose object format and deprecate the other
one to keep things simpler. Thoughts?
</tangential comment>
> So let's assume FALSE in the following. The point of that is that
> such a FALSE setting can't be assumed to have any special intent; it
> will be the default.
>
> [Everything I write here boils down to only one question,
> which I repeat at the end.]
>
> Data gets into a pack in these ways:
> 1. Loose object copied in;
> 2. Loose object newly deltified;
> 3. Packed object to be copied;
> 4. Packed object to be newly deltified;
> 5. Packed deltified object we can't re-use;
> 6. Packed deltified object we can re-use.
> ["copied" includes recompressed.]
I think you forgets "packed undeltified objects we can reuse".
> In (2), (4), and (5), pack.compression will always be newly used.
> If pack.compression doesn't change, this means (6)
> will be using pack.compression since it comes from (2) or (4).
> So if I "guarantee" that (1) uses pack.compression,
> (3) will as well, meaning everything in the pack will be
> at pack.compression.
>
> Thus if pack.compression != core.loosecompression takes precedence
> over core.legacyheaders = false, then for pack.compression constant
> we get all 6 cases at level pack.compression. If core.legacyheaders =
> false takes precedence as you suggest, then all undeltified objects
> (20%?) will be stuck at core.loosecompression [since I see no way
> to sensibly re-apply compression to something copied pack-to-pack].
>
> I think this is inconsistent with what a pack.compression !=
> core.loosecompression setting is telling us.
OK I see that I missed the fact that git-repack -f (or git-pack-objects
--no-reuse-delta) does not recompress undeltified objects. Note this is
a problem in the case where you change pack.compression to a different
value or override it on the command line as well: reused undeltified
objects won't get recompressed with the new level. My rant on
core.legacyheaders and its removal would address the first case. Your
test for a difference between loose and packed compression levels is
flawed because the value of core.compression does not necessarily
represent the compression level that was used for the loose objects to
pack (core.compression might have been modified since then), but it
only addresses the first case too. And this is a problem even now.
What we need instead is a --no-reuse-object that would force
recompression of everything when you really want to enforce a specific
compression level across the whole pack(s).
Nicolas
^ permalink raw reply
* svn user trying to recover from brain damage
From: Joshua Ball @ 2007-05-09 15:30 UTC (permalink / raw)
To: git
Hi all,
The git page says that this mailing list is for "bug reports, feature
requests, comments and patches". Is there a mailing list for new users
crying out for help? If so, forward me there.
OK, I'm feeling very frustrated right now, so let me just say that git
documentation sucks. All the documentation I can find anywhere falls
into two categories:
1. Tutorials for people brand new to version control, with just enough
information for them to "obey the rules", but completely empty of any
information that could help them exploit the real power of
decentralized version control.
2. Technical documentation which assumes pre-obtained knowledge.
Now that I've insulted you and am probably not on your good side...
What the heck do these terms mean? The glossary on the Git wiki was
unhelpful (I'll explain later). BTW, what is wrong with the wiki?
(Particularly the excessive [grayed-out text [no match, add rest:
"used by any common UNIX command. The fact that it is a
mispronunciation of "]]. Is this some new kind of spam, or a buggy
wiki feature?)
HEAD
HEAD REF
working tree
object
branch
merge
master
commit (as in the phrase "bring the working tree to a given commit")
While the Git wiki does in fact define all of these, it doesn't answer
any of my questions about those terms:
Is there a difference between HEAD and the working tree?
Does HEAD change when I cg-switch/git-checkout?
What is an object? Is it a set of patches? A tree snapshot?
What the heck is a branch? (Why does it have so many different
definitions? I feel like every time I come across "branch" in the man
pages, it means something different.)
More on branches: The wiki says that a group of commits linked
together form a DAG. Does that mean every fork/clone/branch-create
possibly doubles the number of branches. So if I fork and then
remerge, do I have two branches?
A -> B -> D
A -> C -> D
Would D be the head of this branch? If so, then heads do not uniquely
identify a branch?
Is there a standard revision notation? (Where my definition of
"revision" is a tree snapshot. In SVN, it would be identified by a
number.) `cg-diff -r A..B` works fine if A and B are branches, but how
do I diff from an older revision to a newer revision? Can I diff
between two revisions which haven't shared the same parent since 2006?
What about the master branch? Is there anything special about it? By
special I mean, do any of the git or cogito commands implicitly assume
that you are working with master? If git is truly decentralized, then
wouldn't master be on an equal footing with all other branches?
What is a merge? My understanding of merge comes from the SVN book,
where it was described as diff+apply. Diff takes 2 arguments, and
apply takes a 1 argument (if the patch is implicit). However, cg-merge
only appears to take one branch. (There again a use of the word
branch! Wouldn't commit or revision be a more accurate term?) Why does
cg-merge only take one argument? Even if I use the -b switch, I'm
still only up to two arguments. Where is the hidden argument?
Lastly, the most important question of all, which may answer many of
the questions above:
Can you fill in the missing pieces, making corrections where
necessary? (recommend unispace font)
Command | Reads | Writes
cg-fetch | remote branch | corresponding branch in local respository
cg-commit | working copy | HEAD
cg-update | remote branch | working copy AND HEAD
cg-merge | branch & working copy | working copy
cg-diff | arguments | STDOUT
cg-push | | remote branch (usually origin)
cg-pull | remote branch |
cg-restore | |
Perhaps the Reads column should be split into two, like ReadInfo and ReadSafety.
ReadInfo would say which revision/branch/commit/object is being read for actual
content, while ReadSafety is only read to make sure that nothing will be lost
after running the command. (e.g., cg-update reads the working copy to make sure
that you are not in a partial merge, but once it knows that it is safe, it
ignores the contents of working directory. I may have this totally wrong.)
On cg-fetch, is the remote branch necessarily remote? Or can you fetch
from local
cg-switch-branches? What does "corresponding branch in local
repository" mean? Does cg-fetch touch your working copy?
What is the difference between cg-restore and cg-seek?
Please reply even if you can only answer one of my many questions! If
I can grab just one fact and say about it, "This is truth", then it
gives me a rock to stand on amidst all the term-mashing out there.
In the words of Dijkstra, "Since breaking out of bad habits, rather
than acquiring new ones, is the toughest part of learning, we must
expect from that system permanent mental damage for most ... exposed
to it."
May you lead me to a quick recovery. Hail to decentralized version control.
Josh "Ua" Ball
^ permalink raw reply
* Re: [PATCH] git-commit: Reformat log messages provided on commandline
From: Matthieu Moy @ 2007-05-09 15:32 UTC (permalink / raw)
To: git
In-Reply-To: <20070509151148.GW4489@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Hmm, I don't really know if it's more evil to split an extra-long line
> to two or keep it longer than the maximum sane width.
The evil already happened several times in git's repository ;-).
$ git log --all --pretty=oneline | grep \
' ................................................................................' \
| wc -l
81
$
When I encounter such long line, I often just don't care, since my
terminal or tool (gitk ...) is often more than 80 char. And in the
cases I care, the fix is just to enlarge the window or to scroll (only
people using a text-mode console would _really_ be disturbed).
With the other solution (breaking the line automatically), I have no
easy fix. In gitk, I have the beginning of a sentence in the summary
field, in a mailed patched, I have the sentence split between the
Subject: header and the body.
(but we agree that both cases are evil. Perhaps just "ERROR: you're
doing evil" would be better ...)
--
Matthieu
^ permalink raw reply
* failing test t9400 (Re: [PATCH] git-update-ref: add --no-deref option for overwriting/detaching ref)
From: Sven Verdoolaege @ 2007-05-09 15:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Frank Lichtenheld
In-Reply-To: <7vk5viuim5.fsf@assigned-by-dhcp.cox.net>
On Wed, May 09, 2007 at 08:22:42AM -0700, Junio C Hamano wrote:
> Can you retry after installing libdbi and libdbd-sqlite-perl?
I'd rather spend my (limited) time on the submodules thing.
Shouldn't these tests be skipped if I don't have all that stuff installed?
There doesn't even seem to be an option to turn off these tests.
Your hunch was correct, btw:
bash-3.00$ sh t9400-git-cvsserver-server.sh --verbose --immediate
* expecting success: cvs -Q co -d cvswork master &&
test "$(echo $(grep -v ^D cvswork/CVS/Entries|cut -d/ -f2,3,5))" = "empty/1.1/"
install_driver(SQLite) failed: Can't locate DBD/SQLite.pm in @INC (@INC contains: /home/skimo/src/git/t/../perl/blib/lib /home/skimo/src/git/t/../perl/blib/arch/auto/Git /usr/lib/perl5/5.8.0/i686-linux-thread-multi /usr/lib/perl5/5.8.0 /usr/lib/perl5/site_perl/5.8.0/i686-linux-thread-multi /usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl .) at (eval 2) line 3, <STDIN> line 16.
Perhaps the DBD::SQLite perl module hasn't been fully installed,
or perhaps the capitalisation of 'SQLite' isn't right.
Available drivers: ExampleP, Proxy.
at /home/skimo/src/git/t/../git-cvsserver line 2212
cvs [checkout aborted]: end of file from server (consult above messages if any)
* FAIL 1: basic checkout
cvs -Q co -d cvswork master &&
test "$(echo $(grep -v ^D cvswork/CVS/Entries|cut -d/ -f2,3,5))" = "empty/1.1/"
skimo
^ permalink raw reply
* Re: quick bare clones taking longer?
From: Junio C Hamano @ 2007-05-09 15:41 UTC (permalink / raw)
To: David Miller; +Cc: git
In-Reply-To: <20070509.020916.80034730.davem@davemloft.net>
David Miller <davem@davemloft.net> writes:
> master.kernel.org just upgraded to git-1.5.1.4 and I notice
> that doing something like this:
>
> git clone --bare -n -l -s ../torvalds/linux-2.6.git test-2.6.git
>
> is no longer an instantaneous operation, it seems to be doing a lot
> of stuff now:
>
> Initialized empty Git repository in /home/davem/git/test-2.6.git/
> remote: Generating pack...
> remote: Done counting 480025 objects.
> remote: Deltifying 480025 objects.
> remote: 100% (480025/480025) done
> Indexing 480025 objects.
> remote: Total 480025 (delta 385878), reused 473265 (delta 379369)
> 100% (480025/480025) done
> Resolving 385878 deltas.
> 100% (385878/385878) done
>
> Is there a new way to get a quick clone?
There is something very wrong. "-l -s" should never go to the
"remote: Generating pack..." codepath. Is that reproducible?
Could you try "sh -x git-clone" it?
^ permalink raw reply
* Re: [FAQ?] Rationale for git's way to manage the index
From: Linus Torvalds @ 2007-05-09 15:52 UTC (permalink / raw)
To: Petr Baudis; +Cc: Martin Langhoff, git
In-Reply-To: <20070509134151.GT4489@pasky.or.cz>
On Wed, 9 May 2007, Petr Baudis wrote:
> On Tue, May 08, 2007 at 06:45:32AM CEST, Linus Torvalds wrote:
> >
> > Or other things like that - I have small test-patches in my tree that I
> > want to build, but that I don't want to commit, and I end up doing big
> > merges and whole patch-application sequences with such a dirty tree
> > (obviously if the patch or merge wants to change that file, I then need to
> > do something about that dirty state, but it happens surprisingly seldom).
>
> Hmm, does this really work so well for you guys? Because thanks to Mr.
> Murphy, in my case, when I have some custom Makefile tweak, I always
> need to commit some unrelated changes involving Makefile more often than
> usual, and so on; so in general case, file-level changes exclusion
> doesn't really work so well for me.
Well, one thing is that I obviously mainly work on a relatively large
project, and one that has been carefully de-centralized over a long long
time, so the source code I work with - the kernel - may be more amenable
to my workflow than most.
For example, we have long long since tried to avoid having central files
that everybody changes - because it's such a pain to manage, even with
good automated merging (and even more with central people still using just
series of patches).
In other words, in well-maintained larger projects, you simply don't see
those kinds of conflicts very often: people don't work on the same files
very much. I regularly go for days, and easily merging hundreds of
thousands of lines of changes, with a dirty tree, and the merges don't
affect it at all.
And if I happen to hit a dirty file, the pull will just say "cannot
merge", and I can stash away my changes, and just re-do. So the cost of a
conflict in a dirty tree is very low when it *does* happen.
> So this use of index seems to me really as a workaround for more
> fine-grained change control (in a similar way that rename following
> would be a workaround for lack of more fine-grained content moves
> tracking). I will have to look into git-gui's hunk-level control and
> maybe reimplement it in tig.
Many people seem to enjoy per-hunk commits, but I seldom do that. Maybe
it's just because I'm *so* comfortable with diffs, that when I clean up an
ugly sequence of commits, what I do is literally:
- I make sure that my ugly sequence of commits is on some temporary
branch, but that the _end_result_ is good and clean (ie I will have
tested the end result fairly well, and made sure that there are no
debug statements etc crud left).
I would call this branch something like "target", because the end
result of that branch is what I'm looking for - even if the commits in
the sequence that gets me there are individually ugly!
- I just switch back to my starting point (and now I'm usually on
"master"), and do
git diff -R target > diff
to create a diff of my current tree (which is initially the starting
point) to the good result.
- I actually edit the "diff" file by hand, and edit it down to the part I
actually want to commit as the first in the series. And then I just do
a "git-apply diff" to actually apply that part to my working tree.
- I then edit any missing parts in the actual working tree (for example,
if there were mixed hunks that I want to get to in later commits, and I
edited out above, or that I need to partially undo), to do any
finishing touches.
- I now have a tree I can compile and test, and has the "first part" of
the journey towards the final "target" state. If compiling/testing
shows that I missed something, I can still fix things, and/or go back
to doing another "git diff -R target" to see if I missed something).
- I commit that first case, and repeat the sequence from step 2 (and
at every step, the "diff" file ends up shrinking and shrinking).
The above sounds like it's a complicated sequence, but it really isn't.
Partly because I just am very comfortable with diffs indeed (probably more
than most people), but partly because at all times "git diff" works fine
to see what I've done, and what the diff to "target" is.
And unlike the "simpler" model of committing individual hunks with "git
add -i" or something like that, my model is actually much superior! It
means that I can actually test each stage individually, and make sure that
the intermediate commits are good. It also allows me to edit up places
where the diff mixes up two different things, and the intermediate result
needs to be different from the final one.
Do I do this very often? No. Most of the time, the changes are separate
enough that I can just commit one file at a time, and in fact, I can mix
and match (ie I can do the above thing in the "big picture", but actually
end up doing one substep where I do just one "diff and edit" phase, but
then actually commit that as two things by just committing individual
files separately when they are obviously independent changes).
But the above is literally what I did for the superproject support and for
some other things where I want to send out the end result in a nice
sequence of 5-6 patches, but when I was actually *developing* it I ended
up making more mistakes, and I started out with 10 patches with some total
braino's that I had to fix, or cleanups that I didn't do in the right
sequence.
And I actually mix-and-match other ways of working too. For example, if
some commit in my otherwise ugly "target" sequence was fine, I'll just
cherry-pick it instead, and re-order things that way.
The point of this all is that the "git way" is actually very flexible. You
can keep the tree dirty and not worry about it, and if you always think
twice before you do "git commit -a" you won't be committing dirty state
that you didn't intend to commit by mistake.
Of course, if you get so used to doing "git commit -a" that you just do it
in your sleep, then the dirty tree model won't work for you, because
you'll simply start committing stuff you didn't intend to commit when
you're on auto-pilot. But the way I work, I basically always do
git diff
to see what's in my tree, and I will only use the "-a" flag when I
*consciously* think "ok, that's all one thing".
Btw, what goes hand-in-hand with this workflow is the nice ability to
specify a subtree. So I'll have a dirty tree with two different
test-things, but since one of them was a filesystem fix, and the other one
was in the kernel, rather than give all the paths explicitly, I'd do
git commit fs/
and it will automatically do the right thing (actually, I often end up
using the two-stage "git add" + "git commit" thing, because one of the
more common cases for me is that I'm going to commit a merge that I fixed
up a conflict in, and then you have to do it that way).
Linus
^ permalink raw reply
* Re: svn user trying to recover from brain damage
From: Carl Worth @ 2007-05-09 16:02 UTC (permalink / raw)
To: Joshua Ball; +Cc: git
In-Reply-To: <92fdc3450705090830t64c8f5b9r4af277807dfe834d@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1543 bytes --]
On Wed, 9 May 2007 10:30:18 -0500, "Joshua Ball" wrote:
> Is there a difference between HEAD and the working tree?
Yes. HEAD is a pointer to committed state. HEAD is an alias for the
current branch.
> Does HEAD change when I cg-switch/git-checkout?
Yes.
> What is an object?
It's a low-level aspect of git's unified storage model. The various
object types, (blob, tree, commit, tag), are defined quite clearly in
the documentation.
> What the heck is a branch?
Simply a pointer to the DAG that moves as new commits are created
while "on" that branch.
> More on branches: The wiki says that a group of commits linked
> together form a DAG.
Yes.
> Does that mean every fork/clone/branch-create
> possibly doubles the number of branches.
No. Creating a new branch simply references some existing commit in
the DAG already.
> So if I fork and then
> remerge, do I have two branches?
>
> A -> B -> D
> A -> C -> D
No. If you merged you would have history that looks like this:
/-> B -\
A D
\-> C -/
> Is there a standard revision notation?
Yes. See the documentation for git-rev-parse and the section on
specifing revisions, (hint: when you run a command like "git log" and
see long sequence of hex characters, you can use those (or abbreviated
versions of those) to name revisons). You can also do many other
things as described in the documentation.
[Beyond this point you bring in too many svn misconceptions to make
the questions easy to answer.]
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] git-update-ref: add --no-deref option for overwriting/detaching ref
From: Johannes Schindelin @ 2007-05-09 16:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: skimo, git
In-Reply-To: <7vk5viuim5.fsf@assigned-by-dhcp.cox.net>
Hi,
On Wed, 9 May 2007, Junio C Hamano wrote:
> Sven Verdoolaege <skimo@kotnet.org> writes:
>
> > git-checkout is also adapted to make use of this new option
> > instead of the handcrafted command sequence.
> >
> > Signed-off-by: Sven Verdoolaege <skimo@kotnet.org>
> > ---
> > All tests pass, except the recently added cvsserver tests,
> > but they fail without this patch too.
>
> Can you retry after installing libdbi and libdbd-sqlite-perl?
We have quite a few tests which are ignored when the prerequisites are not
installed. I wonder if we could do the same with t9400...
Ciao,
Dscho
^ permalink raw reply
* Re: svn user trying to recover from brain damage
From: Karl Hasselström @ 2007-05-09 16:12 UTC (permalink / raw)
To: Carl Worth; +Cc: Joshua Ball, git
In-Reply-To: <874pmmkmsq.wl%cworth@cworth.org>
On 2007-05-09 09:02:29 -0700, Carl Worth wrote:
> [Beyond this point you bring in too many svn misconceptions to make
> the questions easy to answer.]
But do feel free to come with follow-up questions, Joshua! We usually
try our best to be friendly and helpful here, even if it's hard
sometimes not to say mean things about other SCMs. :-)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH] Add a birdview-on-the-source-code section to the user manual
From: Daniel Barkalow @ 2007-05-09 16:18 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Petr Baudis, J. Bruce Fields, kha, junio, git
In-Reply-To: <Pine.LNX.4.64.0705091447110.4167@racer.site>
On Wed, 9 May 2007, Johannes Schindelin wrote:
> > To be honest, I wouldn't even be *thinking* about the endianity of SHA-1
> > octet representation (you don't usually really deal with the hash as
> > with a number, so expecting to have it in native endianity is not very
> > natural; you just deal with it as with a data blob) and the
> > "(big-endian)" would only confuse me and get me thinking about "huh, do
> > they swap the bytes, or wait, they don't, ...?!".
> >
> > But that's maybe just me.
>
> But then, maybe it is just me? I got it completely wrong the first time,
> fully expecting the calculations to be carried out in host endianness for
> performance reasons.
I think the Mozilla implementation carries out calculations in host
endianness, and transfers data from the input to the internal state and
from the internal state to the final hash with shifts and masks.
Which calculations are you seeing that involve byte order?
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: failing test t9400 (Re: [PATCH] git-update-ref: add --no-deref option for overwriting/detaching ref)
From: Junio C Hamano @ 2007-05-09 16:19 UTC (permalink / raw)
To: skimo; +Cc: git, Frank Lichtenheld
In-Reply-To: <20070509153831.GW942MdfPADPa@greensroom.kotnet.org>
Sven Verdoolaege <skimo@kotnet.org> writes:
> On Wed, May 09, 2007 at 08:22:42AM -0700, Junio C Hamano wrote:
>> Can you retry after installing libdbi and libdbd-sqlite-perl?
>
> I'd rather spend my (limited) time on the submodules thing.
Heh, everybody wants to futz with new things ;-)
> Shouldn't these tests be skipped if I don't have all that stuff installed?
> There doesn't even seem to be an option to turn off these tests.
I agree. We would need something like this, but I have no easy
way to test it myself, short of uninstalling what I need on the
box. As you do not have them, maybe you can give it a quick
whirl?
Thanks.
---
diff --git a/t/t9400-git-cvsserver-server.sh b/t/t9400-git-cvsserver-server.sh
index f17be6b..98d6bb4 100755
--- a/t/t9400-git-cvsserver-server.sh
+++ b/t/t9400-git-cvsserver-server.sh
@@ -17,6 +17,11 @@ then
test_done
exit
fi
+perl -e 'use DBI; use DBD::SQLite' 2>&1 || {
+ test_expect_success 'skipping git-cvsserver tests, Perl SQLite interface unavailable' :
+ test_done
+ exit
+}
unset GIT_DIR GIT_CONFIG
WORKDIR=$(pwd)
^ permalink raw reply related
* Re: svn user trying to recover from brain damage
From: Petr Baudis @ 2007-05-09 16:22 UTC (permalink / raw)
To: Joshua Ball; +Cc: git
In-Reply-To: <92fdc3450705090830t64c8f5b9r4af277807dfe834d@mail.gmail.com>
Hi,
On Wed, May 09, 2007 at 05:30:18PM CEST, Joshua Ball wrote:
> The git page says that this mailing list is for "bug reports, feature
> requests, comments and patches". Is there a mailing list for new users
> crying out for help? If so, forward me there.
I think it fits in the "comments" category. :-)
> OK, I'm feeling very frustrated right now, so let me just say that git
> documentation sucks. All the documentation I can find anywhere falls
> into two categories:
>
> 1. Tutorials for people brand new to version control, with just enough
> information for them to "obey the rules", but completely empty of any
> information that could help them exploit the real power of
> decentralized version control.
> 2. Technical documentation which assumes pre-obtained knowledge.
>
> Now that I've insulted you and am probably not on your good side...
>
> What the heck do these terms mean? The glossary on the Git wiki was
> unhelpful (I'll explain later). BTW, what is wrong with the wiki?
> (Particularly the excessive [grayed-out text [no match, add rest:
> "used by any common UNIX command. The fact that it is a
> mispronunciation of "]]. Is this some new kind of spam, or a buggy
> wiki feature?)
Sorry, it was a bug-ridden wiki. I was desperately trying to debug
some weird behaviour, few moments ago I've finally nailed it down and
all should be fine now.
> HEAD
> HEAD REF
> working tree
> object
> branch
> merge
> master
> commit (as in the phrase "bring the working tree to a given commit")
>
> While the Git wiki does in fact define all of these, it doesn't answer
> any of my questions about those terms:
>
> Is there a difference between HEAD and the working tree?
This is (unfortunately) case-sensitive:
HEAD identifies the commit (our slightly confusing name for a
revision) that corresponds to your working tree - usually the latest
commit in your current branch (by default 'master').
head is just the latest commit in a branch, any branch.
> Does HEAD change when I cg-switch/git-checkout?
Yes, HEAD changes (starts pointing to your new branch) when you
cg-switch or git-checkout -b.
> What is an object? Is it a set of patches? A tree snapshot?
Object is the basic unit of stored data Git works with. object may be
either:
"blob" - file at a particular point of time
"tree" - list of files, corresponding to a particular directory
(again at a particular point of time)
"commit" - one revision in the project history; contains
information about the parent commit(s), who did
the commit, the commit message and link to the
corresponding root tree object
"tag" - links to another object, with additional information
like who/when made the tag and the tag comment
Git does not store patches on a conceptual level, only snapshots. (At
the implementation level, Git uses "patches" for more optimized storage,
but that's not so important.)
> What the heck is a branch? (Why does it have so many different
> definitions? I feel like every time I come across "branch" in the man
> pages, it means something different.)
Because it's hard to define. :-)
To make a cyclical definition, branch is the set of commits
referenced by a given head. Hmm, I'll have to think out some cute
non-confusing definition of branch, I'll follow up unless someone beats
me to it.
> More on branches: The wiki says that a group of commits linked
> together form a DAG. Does that mean every fork/clone/branch-create
> possibly doubles the number of branches. So if I fork and then
> remerge, do I have two branches?
>
> A -> B -> D
> A -> C -> D
>
> Would D be the head of this branch? If so, then heads do not uniquely
> identify a branch?
Branch is a much looser concept than you seem to assume. Branch is
really just a fancy name for a 'head', so let's redefine 'head'. Let's
just say for now that 'head' is a named commit reference.
This means that when you create a "new branch" 'foo' from branch
'master', the _only_ thing you really did was to copy the commit
reference 'master.
> Is there a standard revision notation? (Where my definition of
> "revision" is a tree snapshot. In SVN, it would be identified by a
> number.) `cg-diff -r A..B` works fine if A and B are branches, but how
> do I diff from an older revision to a newer revision? Can I diff
> between two revisions which haven't shared the same parent since 2006?
You can diff between any two revisions. The ultimately "standard"
notation is to use the id of the revision (the long string of
hexadecimal digits), but the syntax is quite rich - see SPECIFYING
REVISIONS section of git-rev-parse(1).
If you specify a branch where revision is expected, it means that the
latest commit (revision) on the branch is used.
> What about the master branch? Is there anything special about it? By
> special I mean, do any of the git or cogito commands implicitly assume
> that you are working with master? If git is truly decentralized, then
> wouldn't master be on an equal footing with all other branches?
'master' is just the default name for the first branch in a
repository, but in theory you can name it any way you wish and use as
many branches as you want, all are equal.
When fetching from a remote repository, some commands might assume in
certain conditions that 'master' is the primary branch of the remote
repository, but I'm not sure about the details and in which cases does
this still hold true.
> What is a merge? My understanding of merge comes from the SVN book,
> where it was described as diff+apply. Diff takes 2 arguments, and
> apply takes a 1 argument (if the patch is implicit). However, cg-merge
> only appears to take one branch. (There again a use of the word
> branch! Wouldn't commit or revision be a more accurate term?) Why does
> cg-merge only take one argument? Even if I use the -b switch, I'm
> still only up to two arguments. Where is the hidden argument?
The hidden argument is your current branch. So cg-merge x will merge
the branch 'x' to your current branch: symbolically, kind of
base=-b argument | base(HEAD, x)
apply(HEAD, diff(base, x))
The word 'branch' is used in an attempt to make it all less confusing
:-). But in fact, you can give cg-merge just id of a commit, it does not
have to be branch name.
> Lastly, the most important question of all, which may answer many of
> the questions above:
>
> Can you fill in the missing pieces, making corrections where
> necessary? (recommend unispace font)
>
> Command | Reads | Writes
> cg-fetch | remote branch | corresponding branch in local respository
> cg-commit | working copy | HEAD
> cg-update | remote branch | working copy AND HEAD
> cg-merge | branch & working copy | working copy
> cg-diff | arguments | STDOUT
> cg-push | | remote branch (usually origin)
> cg-pull | remote branch |
> cg-restore | |
Yes, mostly right. cg-merge calls cg-commit unless there are
conflicts, so it should be "working copy AND HEAD" too. cg-push reads
local branch (HEAD or -r argument). There is no cg-pull since people
coming from different VCSes have different ideas about what pull is; git
pull is equivalent to cg-update.
> Perhaps the Reads column should be split into two, like ReadInfo and
> ReadSafety.
> ReadInfo would say which revision/branch/commit/object is being read for
> actual
> content, while ReadSafety is only read to make sure that nothing will be
> lost
> after running the command. (e.g., cg-update reads the working copy to make
> sure
> that you are not in a partial merge, but once it knows that it is safe, it
> ignores the contents of working directory. I may have this totally wrong.)
It actually does some magic so that you can do a merge while having
uncommitted changes in your working tree. ;-)
> On cg-fetch, is the remote branch necessarily remote? Or can you fetch
> from local
> cg-switch-branches? What does "corresponding branch in local
> repository" mean? Does cg-fetch touch your working copy?
Fetch means that a remote branch's content is transferred to the local
repository; furthermore, all the remote branches have their local
counterparts that "reflect" how the branch looked in the remote
repository at a particular point of time. So e.g. when you clone a
repository, the remote default branch is mirrored locally as branch
'origin' - you can't switch to it (technically you could but that would
be very confusing), but you can merge it.
> What is the difference between cg-restore and cg-seek?
cg-seek will temporarily bring your tree to a different commit to
explore the state back then, but you cannot make commits in this state;
your HEAD points to the seeked commit. On the other hand, cg-restore
only changes files in your working tree - it works on the individual
files, does not touch HEAD and does not make the tree "read-only".
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Ever try. Ever fail. No matter. // Try again. Fail again. Fail better.
-- Samuel Beckett
^ permalink raw reply
* Re: [PATCH] Add a birdview-on-the-source-code section to the user manual
From: Johannes Schindelin @ 2007-05-09 16:25 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Petr Baudis, J. Bruce Fields, kha, junio, git
In-Reply-To: <Pine.LNX.4.64.0705091210570.18541@iabervon.org>
Hi,
On Wed, 9 May 2007, Daniel Barkalow wrote:
> On Wed, 9 May 2007, Johannes Schindelin wrote:
>
> > > To be honest, I wouldn't even be *thinking* about the endianity of SHA-1
> > > octet representation (you don't usually really deal with the hash as
> > > with a number, so expecting to have it in native endianity is not very
> > > natural; you just deal with it as with a data blob) and the
> > > "(big-endian)" would only confuse me and get me thinking about "huh, do
> > > they swap the bytes, or wait, they don't, ...?!".
> > >
> > > But that's maybe just me.
> >
> > But then, maybe it is just me? I got it completely wrong the first time,
> > fully expecting the calculations to be carried out in host endianness for
> > performance reasons.
>
> I think the Mozilla implementation carries out calculations in host
> endianness, and transfers data from the input to the internal state and
> >from the internal state to the final hash with shifts and masks.
>
> Which calculations are you seeing that involve byte order?
None. I only suspected them to be carried out in byte order. From what I
know, there are some shifts involved, which might or might not be helped
by 32-bit arithmetic.
I did not really look into it.
>From my prior debugging experiences on Intel, though, I automatically
looked for the least significant bytes at the beginning of those "sha1"
variables, and came up empty.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH v2] Custom compression levels for objects and packs
From: Junio C Hamano @ 2007-05-09 16:26 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Dana How, Git Mailing List
In-Reply-To: <alpine.LFD.0.99.0705091048120.24220@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> So I suggest that we get rid of core.legacyheaders, preserve the legacy
> format as the only writable loose object format and deprecate the other
> one to keep things simpler. Thoughts?
I agree with your analysis, especially when deeper delta chains
are allowed, straight copy of loose object becomes less and less
likely.
> What we need instead is a --no-reuse-object that would force
> recompression of everything when you really want to enforce a specific
> compression level across the whole pack(s).
Yeah. Or maybe --no-reuse to mean both and make '-f' a
short-hand synonym for that.
I do not see much reason to want to tweak them independently;
recomputing delta is much more expensive than recompressing
anyway, and when the user says 'repack -f', it is a sign that
the user is willing to spend CPU cycles.
^ permalink raw reply
* Re: Wiki front page pointing to HelpOnLanguages
From: Petr Baudis @ 2007-05-09 16:26 UTC (permalink / raw)
To: git
In-Reply-To: <vpqr6pu9bdl.fsf@bauges.imag.fr>
Hi,
On Sun, May 06, 2007 at 06:15:34PM CEST, Matthieu Moy wrote:
> Both the URL http://git.or.cz/gitwiki/ and the link "GitWiki" on the
> top-left corner of the wiki seem to point to
> http://git.or.cz/gitwiki/HelpOnLanguages which is a MoinMoin-dedicated
> page, but very confusing for someone looking for informations about
> git.
>
> Reproduced with both Firefox, Konqueror and links, configured in
> English AFAICT, from two different machines.
yes, thanks for the report - I fixed it on Monday, but didn't notice
your mail before now. One of the admins upgraded the machine to etch
when I was not looking and it caused some bits to break. ;-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Ever try. Ever fail. No matter. // Try again. Fail again. Fail better.
-- Samuel Beckett
^ permalink raw reply
* Re: [FAQ?] Rationale for git's way to manage the index
From: Carl Worth @ 2007-05-09 16:29 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Petr Baudis, Martin Langhoff, git
In-Reply-To: <alpine.LFD.0.98.0705090825090.4062@woody.linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 2291 bytes --]
On Wed, 9 May 2007 08:52:09 -0700 (PDT), Linus Torvalds wrote:
[Snip good description of rebuilding a branch to meet some "target"
state.]
That's all really good stuff. And as you mentioned you sometimes use
cherry-pick during this rebuilding, one can also use "git add -i" to
help with splitting up an ugly commit that should have been multiple
commit.
For example, a sequence might look like this, (I always use "desired"
where you use target):
git diff HEAD desired | git apply
git add -i
git commit
git reset --hard
# test here and commit --amend as needed
And repeat that as needed. It's really no different than your "edit
the diff" approach. It's just using "add -i" instead of a text
editor. But I do admit that the commit;reset;test;--amend sequence
might seem a bit too awkward to some people.
> test-things, but since one of them was a filesystem fix, and the other one
> was in the kernel, rather than give all the paths explicitly, I'd do
>
> git commit fs/
>
> and it will automatically do the right thing (actually, I often end up
> using the two-stage "git add" + "git commit" thing, because one of the
> more common cases for me is that I'm going to commit a merge that I fixed
> up a conflict in, and then you have to do it that way).
This reminds me of a confusing semantic issue that came about with the
"new" add. It can be quite natural to commit a single file in one step
with:
git commit some-file.c
or to do that in two steps with:
git add some-file.c
git commit
(which is particularly useful if one wants to add multiple files).
I recently found myself wanting to do a similar thing with a directory
path. I can commit a path with:
git commit path/
but I don't get anything at all like the same semantics if I do:
git add path/
git commit
(since "git add" will recursively add all untracked files under path/).
Now the "recursively add all files" behavior is older, and has been an
essential part of git-add forever. But I found it to be not at all
what I wanted in this case, (where I'm now trained to say "git add" to
stage things into the index).
I don't know of any good fix for the problem now. Maybe I'll just need to
remember to break out that old "git update-index" for a situation like
this, but that sure feels clunky.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Wiki front page pointing to HelpOnLanguages
From: Matthieu Moy @ 2007-05-09 16:30 UTC (permalink / raw)
To: git
In-Reply-To: <20070509162654.GZ4489@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> yes, thanks for the report - I fixed it on Monday, but didn't notice
> your mail before now. One of the admins upgraded the machine to etch
> when I was not looking and it caused some bits to break. ;-)
Great: the formatting was also totally messed up, but I felt someone
was already working on it. That's fixed also.
Good work!
--
Matthieu
^ 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