* Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'
From: Sam Vilain @ 2007-10-19 2:19 UTC (permalink / raw)
To: Jeff King; +Cc: Shawn O. Pearce, git, Nicolas Pitre
In-Reply-To: <20071019021255.GD3290@coredump.intra.peff.net>
Jeff King wrote:
> Boo. I _like_ "deltifying". Sure, it's probably not in the dictionary,
> but that's how languages change: saying "delta compressing" all the time
> will get awkward, so people invent a new word using existing rules to
> explain a common phenomenon.
This is not very considerate to non-native speakers, though, who might
not grasp the neogolism.
Perhaps just "compressing" if it gets awkward.
Sam.
^ permalink raw reply
* Re: Proposed git mv behavioral change
From: Jeff King @ 2007-10-19 2:16 UTC (permalink / raw)
To: Michael Witten; +Cc: Shawn O. Pearce, git
In-Reply-To: <7F18F52A-3D57-4510-B71B-69D43480126E@MIT.EDU>
On Thu, Oct 18, 2007 at 10:07:05PM -0400, Michael Witten wrote:
> I mean to say, if only the index is changed,
> then git won't be informed about the necessary
> git-{add/rm}'s, as in the following (is this
> not so?):
Eh? The changes will make it into history when you commit. Or perhaps I
don't understand your question. Can you rephrase it?
-Peff
^ permalink raw reply
* Re: Proposed git mv behavioral change
From: Shawn O. Pearce @ 2007-10-19 2:15 UTC (permalink / raw)
To: Michael Witten; +Cc: git
In-Reply-To: <7F18F52A-3D57-4510-B71B-69D43480126E@MIT.EDU>
Michael Witten <mfwitten@MIT.EDU> wrote:
> On 18 Oct 2007, at 9:57:15 PM, Shawn O. Pearce wrote:
> >Michael Witten <mfwitten@MIT.EDU> wrote:
> >>
> >>Seems like the shortcut would lose the history and confuse git.
> >
> >No. It wouldn't. The index has no knowledge of history of anything.
>
> I mean to say, if only the index is changed,
> then git won't be informed about the necessary
> git-{add/rm}'s, as in the following (is this
> not so?):
git-add amounts to either inserting a new path->stat/sha1 entry
in the index, or updating an existing entry with new stat/sha1
information.
git-rm amounts to removing a path->stat/sha1 entry from the index.
It's just gone once the git-rm is completed. As if it was never
there to begin with.
A git-commit (really git-write-tree but same difference to the
end-user) stores whatever is in the index as the gospel truth for
how that commit's files should appear. No knowledge about add
or rm is necessary at this stage, we're just taking a copy of the
index and recording that for posterity.
So updating the index is all that is necessary to "remember" these
add and rm operations. OK, well, you also need to actually make
a commit (and not orphan that commit) to have it really stay in
your project. But its all really as simple as it seems.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'
From: Jeff King @ 2007-10-19 2:12 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Nicolas Pitre
In-Reply-To: <20071019004527.GA12930@spearce.org>
On Thu, Oct 18, 2007 at 08:45:27PM -0400, Shawn O. Pearce wrote:
> Recently I was referred to the Grammar Police as the git-pack-objects
> progress message 'Deltifying %u objects' is considered to be not
> proper English to at least some small but vocal segment of the
> English speaking population. Techncially we are applying delta
> compression to these objects at this stage, so the new term is
> slightly more acceptable to the Grammar Police but is also just
> as correct.
Boo. I _like_ "deltifying". Sure, it's probably not in the dictionary,
but that's how languages change: saying "delta compressing" all the time
will get awkward, so people invent a new word using existing rules to
explain a common phenomenon.
Anyway, if you want to please the Grammar Police, should it not be
"Delta-compressing"? "Delta" is not an adverb here, but rather the
phrase acts as a compound verb (i.e., the two words work in place of a
single verb). Although "Delta-compressing objects" just looks stupid.
-Peff
^ permalink raw reply
* Re: Proposed git mv behavioral change
From: Michael Witten @ 2007-10-19 2:07 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20071019015715.GW14735@spearce.org>
On 18 Oct 2007, at 9:57:15 PM, Shawn O. Pearce wrote:
> Michael Witten <mfwitten@MIT.EDU> wrote:
>> On 18 Oct 2007, at 11:47:32 AM, lmage11@twcny.rr.com wrote:
>>
>>> I don't know exactly how git manages the index
>>> internally, but a
>>> shortcut for this would be to simply rename the index entry in
>>> place.
>>
>> Seems like the shortcut would lose the history and confuse git.
>
> No. It wouldn't. The index has no knowledge of history of anything.
I mean to say, if only the index is changed,
then git won't be informed about the necessary
git-{add/rm}'s, as in the following (is this
not so?):
> You're saying that, currently, 'git-mv A.txt path/B.txt'
> does this:
>
> mv A.txt path/B.txt
> git add path/B.txt
> git rm A.txt
>
> So that A.txt is indeed moved to path/B.txt, but now
> A_dirty has been added to the index.
>
> What you want to happen is the following:
>
> git show HEAD:A.txt > path/B.txt
> git add path/B.txt
> mv A.txt B.txt
> git rm A.txt
^ permalink raw reply
* [PATCH 2/2] Documentation/git-gc: improve description of --auto
From: Jeff King @ 2007-10-19 2:05 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Steven Grimm, Brian Gernhardt
This patch tries to make the description of --auto a little
more clear for new users, especially those referred by the
"git-gc --auto" notification message.
It also cleans up some grammatical errors and typos in the
original description, as well as rewording for clarity.
Signed-off-by: Jeff King <peff@peff.net>
---
I started by just trying to fix a couple of grammar issues, but it
seemed quite awkward, and somehow this came out. I think it reads better
than the original, but I'm open to comment.
It is a little bit odd that there is so much low-level detail in the
'--auto' description versus the rest of the page. But I think it reads
OK. Also note that the previous incarnation (and my changes) use the
`foo` form to monospace arguments, while the rest of the page uses 'foo'
(which actually means emphasis). I think the former is more correct, but
asciidoc renders the latter much more pleasantly in manpages. I will see
if I can tweak asciidoc to make this look better.
Documentation/git-gc.txt | 29 +++++++++++++++++------------
1 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/Documentation/git-gc.txt b/Documentation/git-gc.txt
index 83843a5..872056e 100644
--- a/Documentation/git-gc.txt
+++ b/Documentation/git-gc.txt
@@ -45,18 +45,23 @@ OPTIONS
few hundred changesets or so.
--auto::
- With this option, `git gc` checks if there are too many
- loose objects in the repository and runs
- gitlink:git-repack[1] with `-d -l` option to pack them.
- The threshold for loose objects is set with `gc.auto` configuration
- variable, and can be disabled by setting it to 0. Some
- Porcelain commands use this after they perform operation
- that could create many loose objects automatically.
- Additionally, when there are too many packs are present,
- they are consolidated into one larger pack by running
- the `git-repack` command with `-A` option. The
- threshold for number of packs is set with
- `gc.autopacklimit` configuration variable.
+ With this option, `git gc` checks whether any housekeeping is
+ required; if not, it exits without performing any work.
+ Some git commands run `git gc --auto` after performing
+ operations that could create many loose objects.
++
+Housekeeping is required if there are too many loose objects or
+too many packs in the repository. If the number of loose objects
+exceeds the value of the `gc.auto` configuration variable, then
+all loose objects are combined into a single pack using
+`git-repack -d -l`. Setting the value of `gc.auto` to 0
+disables automatic packing of loose objects.
++
+If the number of packs exceeds the value of `gc.autopacklimit`,
+then existing packs (except those marked with a `.keep` file)
+are consolidated into a single pack by using the `-A` option of
+`git-repack`. Setting `gc.autopacklimit` to 0 disables
+automatic consolidation of packs.
Configuration
-------------
--
1.5.3.4.1249.g895be-dirty
^ permalink raw reply related
* [PATCH 1/2] Documentation/git-gc: explain --auto in description
From: Jeff King @ 2007-10-19 2:01 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Steven Grimm, Brian Gernhardt
Now that git-gc --auto tells the user to look at the man
page, it makes sense to mention the auto behavior near the
top (since this is likely to be most users' first exposure
to git-gc).
Signed-off-by: Jeff King <peff@peff.net>
---
Documentation/git-gc.txt | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-gc.txt b/Documentation/git-gc.txt
index b9d5660..83843a5 100644
--- a/Documentation/git-gc.txt
+++ b/Documentation/git-gc.txt
@@ -19,7 +19,8 @@ created from prior invocations of gitlink:git-add[1].
Users are encouraged to run this task on a regular basis within
each repository to maintain good disk space utilization and good
-operating performance.
+operating performance. Some git commands may automatically run
+`git-gc`; see the `--auto` flag below for details.
OPTIONS
-------
--
1.5.3.4.1249.g895be-dirty
^ permalink raw reply related
* Re: Proposed git mv behavioral change
From: Shawn O. Pearce @ 2007-10-19 1:57 UTC (permalink / raw)
To: Michael Witten; +Cc: lmage11, git
In-Reply-To: <D2EAAC6D-567D-454A-AECA-C90FA2C369AE@mit.edu>
Michael Witten <mfwitten@MIT.EDU> wrote:
> On 18 Oct 2007, at 11:47:32 AM, lmage11@twcny.rr.com wrote:
>
> >I don't know exactly how git manages the index
> >internally, but a
> >shortcut for this would be to simply rename the index entry in place.
>
> Seems like the shortcut would lose the history and confuse git.
No. It wouldn't. The index has no knowledge of history of anything.
For good reason. Its strictly a mapping of file name to some basic
stat information (used to determine if the file has been modified
by the user or not) and the SHA-1 of the staged blob. That's it.
No history. The shortcut the original poster was asking about
wouldn't confuse Git one bit.
--
Shawn.
^ permalink raw reply
* Re: Proposed git mv behavioral change
From: Shawn O. Pearce @ 2007-10-19 1:54 UTC (permalink / raw)
To: lmage11; +Cc: git
In-Reply-To: <c594999b2337.2337c594999b@nyroc.rr.com>
Line wrapping email at under 80 columns would be nice. It makes it
easier to read the message, and more importantly, easier to quote
a few times during discussion.
lmage11@twcny.rr.com wrote:
> Therefore, I propose that git mv's behavior be changed. I think it
> would make far more sense for a move to only change the actual name
> of the file and to not pull in unstaged changes. In other words,
> I'd like the index entry for the original file name to be removed
> and an index entry to be added with a different name, but using the
> exact same blob hash as the original file. I don't know exactly how
> git manages the index internally, but a shortcut for this would be
> to simply rename the index entry in place.
I'm somewhat hesistant to change existing behavior, as users may
be used to it or relying upon it within their scripts. But you
make an excellent argument about why the current git-mv behavior
is perhaps less than ideal.
Elsewhere in git we use the --cached command line option to mean
"only make the change in the index". For example the git-apply
--cached option. You could start a patch that uses --cached to
trigger the new behavior you propose and see if people are interested
in changing the default once the feature is working and available
for experimentation.
> I'm willing to look into what changes would need to be made to the
> code for this change to happen; I'm not asking for someone to do
> all the work for me. :)
>
> So... Yeah. I'd like to know what people think about this before
> I put a significant amount of effort into it. After all, we know
> how lazy programmers are... :)
See builtin-mv.c around l.264-283. This is where we are removing
the old names from the index (in memory) and inserting the new
names. Instead of calling add_file_to_cache() you would want
to use something like add_cacheinfo() in builtin-update-index.c,
specifying the old sha1, ce_flags and ce_mode.
I'm sure Junio could probably give you a better starting point
than I can, as he's more familiar with this sort of code, but that
should still get you looking in the right direction and maybe get
a working implementation together that you can share for discussion.
--
Shawn.
^ permalink raw reply
* Re: Proposed git mv behavioral change
From: Michael Witten @ 2007-10-19 1:47 UTC (permalink / raw)
To: lmage11; +Cc: git
In-Reply-To: <c594999b2337.2337c594999b@nyroc.rr.com>
On 18 Oct 2007, at 11:47:32 AM, lmage11@twcny.rr.com wrote:
> I don't know exactly how git manages the index
> internally, but a
> shortcut for this would be to simply rename the index entry in place.
Seems like the shortcut would lose the history and confuse git.
Anyway,
Let's say you have a file, A.txt, with contents:
A
You edit this file so that it has contents:
A_dirty
You're saying that, currently, 'git-mv A.txt path/B.txt'
does this:
mv A.txt path/B.txt
git add path/B.txt
git rm A.txt
So that A.txt is indeed moved to path/B.txt, but now
A_dirty has been added to the index.
What you want to happen is the following:
git show HEAD:A.txt > path/B.txt
git add path/B.txt
mv A.txt B.txt
git rm A.txt
Is this correct?
Michael Witten
^ permalink raw reply
* [PATCH] Avoid invoking diff drivers during git-stash
From: Shawn O. Pearce @ 2007-10-19 1:33 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Git Mailing List
In-Reply-To: <47171A21.9030003@viscovery.net>
git-stash needs to restrict itself to plumbing when running automated
diffs as part of its operation as the user may have configured a
custom diff driver that opens an interactive UI for certain/all
files. Doing that during scripted actions is very unfriendly to
the end-user and may cause git-stash to fail to work.
Reported by Johannes Sixt
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
Johannes Sixt <j.sixt@viscovery.net> wrote:
> (1) Looking at git-stash.sh I see a few uses of 'git diff' in
> apply_stash(). Shouldn't these use one of git-diff-{tree,index,files)? The
> reason is that porcelain 'git diff' invokes custom diff drivers (that in my
> case run a UI program), whereas the plumbing does not.
>
> Is there a particular reason to use porcelain 'git diff'?
Does this fix the problem?
git-stash.sh | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/git-stash.sh b/git-stash.sh
index 7ba6162..def3163 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -110,7 +110,7 @@ show_stash () {
w_commit=$(git rev-parse --verify "$s") &&
b_commit=$(git rev-parse --verify "$s^") &&
- git diff $flags $b_commit $w_commit
+ git diff-tree $flags $b_commit $w_commit
}
apply_stash () {
@@ -139,7 +139,7 @@ apply_stash () {
unstashed_index_tree=
if test -n "$unstash_index" && test "$b_tree" != "$i_tree"
then
- git diff --binary $s^2^..$s^2 | git apply --cached
+ git diff-tree --binary $s^2^..$s^2 | git apply --cached
test $? -ne 0 &&
die 'Conflicts in index. Try without --index.'
unstashed_index_tree=$(git-write-tree) ||
@@ -162,7 +162,7 @@ apply_stash () {
git read-tree "$unstashed_index_tree"
else
a="$TMP-added" &&
- git diff --cached --name-only --diff-filter=A $c_tree >"$a" &&
+ git diff-index --cached --name-only --diff-filter=A $c_tree >"$a" &&
git read-tree --reset $c_tree &&
git update-index --add --stdin <"$a" ||
die "Cannot unstage modified files"
--
1.5.3.4.1249.g895be
^ permalink raw reply related
* Re: git stash apply usability issues
From: Shawn O. Pearce @ 2007-10-19 1:31 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Git Mailing List
In-Reply-To: <47171A21.9030003@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> wrote:
> (2) when 'git stash apply' runs merge-recursive, it treats the current
> state as 'ours' and the stash as 'theirs'. IMHO it should be the other way
> round: I have stashed away changes to a binary file. Then committed a
> different modification to it, and now want to apply the stash. This results
> in a conflict that leaves the current state in the working tree, but I had
> preferred that the stashed binary file were in the working tree now.
>
> What do other git-stash users think about changing the order?
The current order is the same order that git-rebase uses. I'm not
saying its correct, just that its the same as rebase. I think rebase
is also backwards and if we change git-stash we should also change
git-rebase at the same time (though probably not in the same commit).
--
Shawn.
^ permalink raw reply
* Re: [PATCH] git-gc: improve wording of --auto notification
From: Jeff King @ 2007-10-19 1:26 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Steven Grimm, Brian Gernhardt, git
In-Reply-To: <20071019012430.GT14735@spearce.org>
On Thu, Oct 18, 2007 at 09:24:30PM -0400, Shawn O. Pearce wrote:
> I think what you have is many times better. It doesn't tell the
> user that they can prevent having this activate at the wrong time
> by just running git-gc every so often, but if the message (and
> the subsequent packing itself) is annoying they'll read the manual
> entry and hopefully figure that out on their own.
Yes, I tried many wordings of "this is annoying and you want to avoid
it," but explaining the situation takes way too much time for such a
commonly seen message. And I think some people will actually prefer it
that way.
BTW, the git-gc manpage needs some cleanup. Patches to follow.
-Peff
^ permalink raw reply
* Re: [PATCH] git-gc: improve wording of --auto notification
From: Shawn O. Pearce @ 2007-10-19 1:24 UTC (permalink / raw)
To: Jeff King; +Cc: Steven Grimm, Brian Gernhardt, git
In-Reply-To: <20071019011211.GC3290@coredump.intra.peff.net>
Jeff King <peff@peff.net> wrote:
> Shawn said:
> > A patch against spearce/master to revert the prior message and insert
> > something that is perhaps more reasonable would be most appreciated.
>
> Geez, you really _are_ the maintainer now, prodding your minions to
> write trivial patches for you. :)
Heh. But didn't I just post a different trivial patch to the
mailing list not 15 minutes ago? :-)
> I don't see any point in reverting the
> other patch separately, since we can just improve the message.
I agree. No point in pissing in the snow multiple times over a
simple language change. I was perhaps a little too aggressive in
applying Steven's first patch. Which I also now see git-am actually
split the From line incorrectly and doesn't actually show Steven's
name in the author field. Arrgh.
> I tried not to use the word "avoid" since I think we don't want to imply
> that auto-gc sucks. It doesn't, but some people might prefer to run it
> manually, and we should let them know it's an option. I'm open to
> wording improvements.
I think what you have is many times better. It doesn't tell the
user that they can prevent having this activate at the wrong time
by just running git-gc every so often, but if the message (and
the subsequent packing itself) is annoying they'll read the manual
entry and hopefully figure that out on their own.
> fprintf(stderr, "Packing your repository for optimum "
> + "performance. You may also\n"
> + "run \"git gc\" manually. See "
> + "\"git help gc\" for more information.\n");
--
Shawn.
^ permalink raw reply
* Re: Application to install man pages.
From: Shawn O. Pearce @ 2007-10-19 1:16 UTC (permalink / raw)
To: Evan Carroll; +Cc: git
In-Reply-To: <428b865e0710181159i7a12f2b7y22619f0eaf36d2c1@mail.gmail.com>
Evan Carroll <me@evancarroll.com> wrote:
> This is a one liner but might help for simply a quick install of the
> git manpages.
...
> +#/bin/sh
> + cp -R --copy-contents ./man* /usr/local/man
> --
Isn't this covered by the "make -C Documentation quick-install"?
Which is what "make quick-install-doc" does in the top level Makefile.
--
Shawn.
^ permalink raw reply
* [PATCH] git-gc: improve wording of --auto notification
From: Jeff King @ 2007-10-19 1:12 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Steven Grimm, Brian Gernhardt, git
In-Reply-To: <20071019001648.GO14735@spearce.org>
The previous message had too much of a "boy, you should
really turn off this annoying gc" flair to it. Instead,
let's make sure the user understands what is happening, that
they can run it themselves, and where to find more info.
Suggested by Brian Gernhardt.
Signed-off-by: Jeff King <peff@peff.net>
---
Shawn said:
> A patch against spearce/master to revert the prior message and insert
> something that is perhaps more reasonable would be most appreciated.
Geez, you really _are_ the maintainer now, prodding your minions to
write trivial patches for you. :) I don't see any point in reverting the
other patch separately, since we can just improve the message.
I tried not to use the word "avoid" since I think we don't want to imply
that auto-gc sucks. It doesn't, but some people might prefer to run it
manually, and we should let them know it's an option. I'm open to
wording improvements.
builtin-gc.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/builtin-gc.c b/builtin-gc.c
index f99b212..3a2ca4f 100644
--- a/builtin-gc.c
+++ b/builtin-gc.c
@@ -206,9 +206,9 @@ int cmd_gc(int argc, const char **argv, const char *prefix)
if (!need_to_gc())
return 0;
fprintf(stderr, "Packing your repository for optimum "
- "performance. If you would rather run\n"
- "\"git gc\" by hand, run \"git config gc.auto 0\" "
- "to disable automatic cleanup.\n");
+ "performance. You may also\n"
+ "run \"git gc\" manually. See "
+ "\"git help gc\" for more information.\n");
} else {
/*
* Use safer (for shared repos) "-A" option to
--
1.5.3.4.1249.g895be-dirty
^ permalink raw reply related
* Re: git-merge: need a tap with the cluestick, please
From: walt @ 2007-10-19 1:00 UTC (permalink / raw)
To: git
In-Reply-To: <20071018233518.GL14735@spearce.org>
Shawn O. Pearce wrote:
> walt <wa1ter@myrealbox.com> wrote:
>> Now when I pull from Linus the merge stops in the middle because of
>> conflicts with my .gitignore file <sigh>. Anything I try now with
>> git-merge tells me I can't do that in the middle of a conflicted
>> merge. Yes, I know that now, but what should I do instead?
>>
>> I could move my 'obj' out-of-tree but then I wouldn't learn anything.
>> This has to be bone-head easy, but not for me :)
>
> How about putting the ignore for your obj dir in your own private
> exclude file:
>
> $ echo /obj >>.git/info/exclude
>
> will cause Git to ignore an "obj" directory if it is found in the
> top level of the repository. And since this file is not actually
> tracked as part of the repository it will apply to all branches
> in this repository and won't cause merge conflicts when upstream
> makes changes to .gitignore.
Thanks to both you and Lars, who gave me the same advice off-list.
I will do exactly that.
Just to illustrate how much of life depends on blind luck, both good
and bad, I'll explain what really got me in trouble here. On the
very first pull from Linus after I added my obj directory to
.gitignore -- I pulled this commit:
commit 9e447a7f1fd997bcb9266899e777c37469245365
Author: Denis V. Lunev <den@openvz.org>
Date: Tue Oct 16 11:22:21 2007 +0400
.gitignore update for x86 arch
This patch: - makes .gitignore files visible to git
I'd like to think that if I'd made my changes on *any* other day
but yesterday I wouldn't have been so completely confused by what
happened. (But perhaps I flatter myself :o)
Thanks again.
^ permalink raw reply
* Re: Qgit performance and maintain CVS environment with GIT repository
From: Johannes Schindelin @ 2007-10-19 0:50 UTC (permalink / raw)
To: Pete/Piet Delaney
Cc: Marco Costalba, Robin Rosenberg, piet.delaney, Linus Torvalds,
VMiklos, free cycle, git, piet.delaney, Piet Delaney
In-Reply-To: <4717F8CF.9060103@bluelane.com>
Hi,
On Thu, 18 Oct 2007, Pete/Piet Delaney wrote:
> I'll try the git-cvsserver path. If anyone has any war stories to share
> on the path this would be an ideal time to share them.
I was responsible for a medium long running CVS repository, and I wanted
to switch to git. For a long time, I just ran tests and tried to flesh
out things, and eventually went for it.
A few of the patches to git-cvsserver from me were direct results of
problems we ran to. But mind you, that was almost over a year ago.
In the meantime, many of my developers switched. Some because it was
easier than waiting for me to fix the bugs with the cvs server.
Some because they saw me working with git.
I still do not know why the third group switched.
Now I have exactly one dev left, who refuses to use anything else than
cvs. Fine with me. I can live with other people using inferiour programs
than myself.
I even patched cvsserver not to print the "committed using git-cvsserver"
message locally.
But then, I was never a cvs "power" user. Only a git power user.
Ciao,
Dscho
^ permalink raw reply
* Re: git push bug?
From: Shawn O. Pearce @ 2007-10-19 0:49 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: Steffen Prohaska, git
In-Reply-To: <1192723847.9433.25.camel@gentoo-jocke.transmode.se>
Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> BTW this does not work either:
>
> git reset --hard HEAD^
> git push -f ssh://devsrv/var/git/os2kernel.git +master:master
> updating 'refs/heads/master'
> from 9c344d18d01221c8f25080cb58910e6b09efbf55
> to 5761a9e5924b34615c748fba2dcb977ed04c1243
> Generating pack...
> Done counting 0 objects.
> Writing 0 objects...
> Total 0 (delta 0), reused 0 (delta 0)
> error: denying non-fast forward refs/heads/master (you should pull first)
> ng refs/heads/master non-fast forward
> error: failed to push to 'ssh://devsrv/var/git/os2kernel.git'
>
> I thought the + in +master:master and the -f option should let me
> do that.
Yes, but its only on the client side.
See when we do a push the local client side determines if the push is
going to be a fast-forward or not. If it isn't then the git-push
client aborts before it even uploads data to the remote side.
The --force or + can be used to make the client side skip this
check and just plow forward anyway.
But the remote side can also veto a non-fast-forward update. By
default it refuses to allow such updates as they can orphan commits
(and thus potentially lose important work). See the config option
receive.denyNonFastForwards; you may want to set this to true in
the remote side's config file.
--
Shawn.
^ permalink raw reply
* [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'
From: Shawn O. Pearce @ 2007-10-19 0:45 UTC (permalink / raw)
To: git; +Cc: Nicolas Pitre
Recently I was referred to the Grammar Police as the git-pack-objects
progress message 'Deltifying %u objects' is considered to be not
proper English to at least some small but vocal segment of the
English speaking population. Techncially we are applying delta
compression to these objects at this stage, so the new term is
slightly more acceptable to the Grammar Police but is also just
as correct.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
To go on top of your 'np/progress' series that is currently in next.
I think it might keep us out of trouble with certain individuals...
builtin-pack-objects.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 15d3750..f79fc0b 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -1718,7 +1718,7 @@ static void prepare_pack(int window, int depth)
if (nr_deltas && n > 1) {
unsigned nr_done = 0;
if (progress)
- start_progress(&progress_state, "Deltifying objects",
+ start_progress(&progress_state, "Delta compressing objects",
nr_deltas);
qsort(delta_list, n, sizeof(*delta_list), type_size_sort);
ll_find_deltas(delta_list, n, window+1, depth, &nr_done);
--
1.5.3.4.1249.g895be
^ permalink raw reply related
* Re: Qgit performance and maintain CVS environment with GIT repository
From: Jeff King @ 2007-10-19 0:41 UTC (permalink / raw)
To: Pete/Piet Delaney
Cc: Johannes Schindelin, Marco Costalba, Robin Rosenberg,
piet.delaney, Linus Torvalds, VMiklos, free cycle, git,
piet.delaney, Piet Delaney
In-Reply-To: <4717F8CF.9060103@bluelane.com>
On Thu, Oct 18, 2007 at 05:22:39PM -0700, Pete/Piet Delaney wrote:
> I've got root access on the CVS server and want to switch to git without
> disturbing the environment more than is necessary to make the switch.
> I think developers will want to us git and git-cvsserver looks like
> the more likely desirable path.
Depending on the environment and the willingness of people to change to
git, it might be worth moving slowly and keeping the backend as CVS at
first. I.e., keep the "official" repository as CVS, and let some devs
start moving to access through git-cvsimport and git-cvsexportcommit
(and maybe even provide an official git repo which is backed by the CVS
repo, so that all of the import/export happens in one place). That will
give them time to get used to git, give those who are resistant to the
change their original interface, and if anything goes wrong, you can
always fall back to the "old" way.
And then when everything seems to be going well, swap it. Make git the
official repo, but provide a "legacy" CVS access for the die-hards
(using git-cvsserver).
And then eventually just shut off CVS access entirely (when everyone is
happier using git).
Of course none of that is necessary, but one of the nice things about
git is how it can integrate with existing setups, so you can really ease
into a transition without investing a lot of resources.
-Peff
^ permalink raw reply
* Re: Splitting a repository
From: Jeff King @ 2007-10-19 0:33 UTC (permalink / raw)
To: Gonzalo Garramuno; +Cc: git
In-Reply-To: <47179944.6080608@filmaura.com>
On Thu, Oct 18, 2007 at 02:35:00PM -0300, Gonzalo Garramuno wrote:
> I have a project I have been working on for some time and one of its
> libraries has grown too much.
> I'm now wanting to split that library into a separate git repository.
> I'm wondering what's the best way to go around this. Ideally I would like
> to have:
Look at the documentation for "git-filter-branch". You can make a new
history for each of the split parts that you want.
-Peff
^ permalink raw reply
* Re: git push bug?
From: Shawn O. Pearce @ 2007-10-19 0:24 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: joakim.tjernlund, git
In-Reply-To: <0DAC53EF-021D-441C-9520-9795AAB6DE54@zib.de>
Steffen Prohaska <prohaska@zib.de> wrote:
> On Oct 18, 2007, at 4:50 PM, Joakim Tjernlund wrote:
> >
> ># > git push ssh://devsrv/var/git/os2kernel.git linus:refs/linus
...
> >error: refusing to create funny ref 'refs/linus' locally
> >ng refs/linus funny refname
> >error: failed to push to 'ssh://devsrv/var/git/os2kernel.git'
...
> You may need to cleanup though. I'm not sure if the remote side
> already created 'refs/linus'. The error message only indicates that
> locally git refused to create the "funny refname".
Cute. The error message "error: refusing to create .. locally"
is actually coming from the remote site. Locally here is
actually remotely. We *really* should change that. Its l.169 of
receive-pack.c, which is only running on the remote side. :)
Anyone game to improve that error message? Should be a pretty
simple patch. One of the may low-hanging fruits in Git.
--
Shawn.
^ permalink raw reply
* Re: Qgit performance and maintain CVS environment with GIT repository
From: Pete/Piet Delaney @ 2007-10-19 0:22 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Marco Costalba, Robin Rosenberg, piet.delaney, Linus Torvalds,
VMiklos, free cycle, git, piet.delaney, Piet Delaney
In-Reply-To: <Pine.LNX.4.64.0710190054570.25221@racer.site>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Johannes Schindelin wrote:
> Hi,
>
> On Thu, 18 Oct 2007, Pete/Piet Delaney wrote:
>
>> Johannes:
>> I read somewhere in the past week that it was possible to maintain
>> our existing CVS environment with git. I though it was a separate
>> package to export git back to cvs but I just noticed a git-cvsserver
>> and as a std part of git and was wondering about using that.
>
> Where did you read that?
Don't recall exactly, I thought it was a page like the one showing
git Related tools but didn't find it today when looking for it.
> AFAIK git-cvsserver is one option. The other is
> cvsexportcommit. The former is more appropriate if you want to switch the
> developers over to git, and want to provide a smooth path for the devs (or
> cannot convert a few hardcore CVS "fans").
>
> The latter is appropriate if you cannot control the server side, or are
> not allowed to switch to CVS.
I've got root access on the CVS server and want to switch to git without
disturbing the environment more than is necessary to make the switch.
I think developers will want to us git and git-cvsserver looks like
the more likely desirable path.
>
>> We have a number of build machines with flamebox perl scripts pulling
>> out CVS branches for builds. I was wondering what is the best way to use
>> git and it's nicer pull/push model and merge facility and possibly
>> maintain CVS exports for scripts doing builds if possible the cvsweb and
>> bonsai (CVS Query Form) that a number of engineers are currently using.
>
> I don't know how cvsweb copes with git-cvsserver, but I guess that there
> will be no problem.
great.
>
>> I started looking over out flamebox scripts with the intent up
>> converting them over to git but I mentioned the git to cvs coexistence
>> and we are wondering if that's a better route than upgrading the
>> flamebox scripts. Having our existing cvsweb, bonsai, and gitweb along
>> with the git utilities seems at least desirable. Any thoughts or
>> suggestions?
>
> My suggestion: if you're fine with CVS, stick with it. Really. I am not
> here to teach the whole world about the advantages of git, so by all
> means, if you yourself do not find any advantage to using git, don't use
> it. Stick with what works for you.
We are definitely not fine with CVS, the branch merging isn't
comfortable. I'm just wondering about maintaining the existing
CVS browsers and the build scripts if it's not a big deal. I'll
try the git-cvsserver path. If anyone has any war stories to share
on the path this would be an ideal time to share them.
- -piet
>
> Ciao,
> Dscho
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHF/jPJICwm/rv3hoRAkXgAJ9pa/DHxka926i3FHqYTsxCb5kzcQCeKiSk
j/Paxc6tJemOPK0TV8MhFGs=
=ut2Q
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [BUG] git remote add failure
From: Shawn O. Pearce @ 2007-10-19 0:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Guido Ostkamp, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0710181708230.25221@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Thu, 18 Oct 2007, Guido Ostkamp wrote:
>
> > I think I've found a bug in "git remote add". I tried the following:
> >
> > $ git remote add -f spearce2 http://repo.or.cz/git/spearce.git
> > Cannot get the repository state from http://repo.or.cz/git/spearce.git
> > fetch spearce2: command returned error: 1
> >
> > Obviously I used the wrong URI. Then I tried again:
> >
> > $ git remote add -f spearce2 http://repo.or.cz/r/git/spearce.git
> > remote spearce2 already exists.
> >
> > I think Git should not store the bad info and block the name when the
> > first call wasn't successfull.
>
> The problem there is of course that the fetch could fail because you are
> offline. In that case, you do not want git remote to throw the
> information away.
Right. But maybe there should be an easier way for the user to
"force" adding the remote over the existing remote. Much like how
they can force creating a branch over an existing branch.
Too bad -f is already taken. :-\
--
Shawn.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox