* Re: Cleaning up git user-interface warts
From: Shawn Pearce @ 2006-11-15 18:49 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Linus Torvalds, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0611151315291.2591@xanadu.home>
Nicolas Pitre <nico@cam.org> wrote:
> As for the fraction of people complaining being a small fraction of
> current GIT users: that is easily explainable by the fact that most
> people who would have grown the complainers group are simply not GIT
> users anymore since they were turned away by GIT's current user
> interface issues. The only complainers remaining are those who see
> value in the GIT technology but who would like to bring more
> intuitiveness to the GIT interface instead of going for the alternative
> technology. And those kind of people are always few.
Or they are by proxy.
*I* don't see that much of a problem with git pull; I can use it
without trouble at this point. But I find it difficult to teach
to others.
My complaints about git pull/fetch/push are by proxy for about 10
other users who aren't on the mailing list but whom I interact with
through Git. They don't like pull/fetch/push very much.
So count my complaints 10 times. :)
Ok, that's still a drop in the bucket of current Git users.
But still, I'm sure there are others. I think Carl was recently
talking about complaints from some Fedora folks...
--
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Andy Parkins @ 2006-11-15 18:58 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0611150950170.3349@woody.osdl.org>
On Wednesday 2006, November 15 18:03, Linus Torvalds wrote:
> Guys, before you start thinking this way, the fact is, there's a lot of
> happy git users.
I'm a happy user, doesn't mean I wouldn't like changes. In fact, by that
argument, that there are happy users means that there is no need to ever make
changes.
> - git itself has now done it that way for the last 18 months, and the
> fact is, the people _complaining_ are a small subset of the people who
> actually use git on a daily basis and don't complain.
That's awfully like the argument I hear off my bank whenever I complain to
them too - "well lots of other people don't complain so we must be right".
The people who complain are a subset of the people who have complaints. I
don't think never changing is a good argument - leaving aside the actual
changes under discussion - in another 18 months lets say there are double the
number of git users, and 18 months after that double again - in that case the
potential new users needs outweigh the current users needs.
> If you think "pull" is confusing, I can guarantee you that _changing_ the
> name is a hell of a lot more confusing. In fact, I think a lot of the
> But the fact is, git isn't really that hard to work out, and the commands
On the one hand you're arguing that git syntax is easy to learn, and on the
other that no one will be able to learn a new syntax just as easily.
> aren't that complicated. There's no reason to rename them. We do have
> other problems:
That there are other problems doesn't negate these problems.
> But trying to rename "pull" (or the "git" name itself) is just going to
> cause more confusion than you fix.
I don't think so. Mainly because the proposed new git pull would be a subset
of the existing git pull. It's not changing function, it's just reducing in
function.
Andy
--
Dr Andrew Parkins, M Eng (Hons), AMIEE
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Andy Parkins @ 2006-11-15 19:02 UTC (permalink / raw)
To: git
In-Reply-To: <7vbqn8o9st.fsf@assigned-by-dhcp.cox.net>
On Wednesday 2006, November 15 18:16, Junio C Hamano wrote:
> I still think in the long run you would be better off giving
> separate names to Porcelains because I am sure you are going to
The problem I think with that is that the line between plumbing and porcelain
is not clear. If you have two names then for the ambiguous ones you are just
making it more confusing because there is yet another variable to try before
you get the function you want.
Andy
--
Dr Andrew Parkins, M Eng (Hons), AMIEE
^ permalink raw reply
* Re: [GIT PATCH] Makefile missing git-runstatus in PROGRAMS list
From: Junio C Hamano @ 2006-11-15 19:04 UTC (permalink / raw)
To: Bhavesh Davda; +Cc: git
In-Reply-To: <FE74AC4E0A23124DA52B99F17F44159701A11D6D@PA-EXCH03.vmware.com>
"Bhavesh Davda" <bhavesh@vmware.com> writes:
> Indeed! I had "export CDPATH=.:$HOME" in my $HOME/.bash_profile.
>
> "export -n CDPATH", and now "make install" works, setting up those hard links
> too.
>
> If this is a common gotcha in building and installing git, maybe you should
> add it near the top of the INSTALL instructions.
>
> I haven't run into this issue with other projects. Is there something that
> can be changed in git's Makefile so it works even if CDPATH is set and
> exported in people's environments?
I think we already had this discussed twice on this list.
The problem is not just Makefile, but any command implemented as
shell scripts, if it needs to "cd" inside, is bitten by exported
CDPATH not just because it gives unwanted output to stdout
(which is already stupid -- CDPATH is purely convenience for
interactive session) but also because it would take the process
to unexpected places.
You can solve it by three ways. (1) unset CDPATH at the
beginning of every shell script; (2) write all internal "cd" in
such a way that CDPATH would not try to interfere with it; (3)
teach users to fix their broken environment.
We do (1) for our shell scripts with git-sh-setup which almost
all other script sources, along with a comment for (3) at that
place. As you say we should probably add the same to INSTALL
instructions.
^ permalink raw reply
* Re: [PATCH] Seek back to current filepos when mmap()ing with NO_MMAP
From: Alex Riesen @ 2006-11-15 19:06 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: junkio, git
In-Reply-To: <Pine.LNX.4.63.0611151727000.13772@wbgn013.biozentrum.uni-wuerzburg.de>
[-- Attachment #1: Type: text/plain, Size: 450 bytes --]
On 11/15/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> "git-index-pack --fix-thin" relies on mmap() not changing the current
> file position (otherwise the pack will be corrupted when writing the
> final SHA1). Meet that expectation.
>
Thanks! I was wondering for some considerable time why the
hell t5500-fetch-pack fails.
BTW, I extended error handling in that mmap. Dunno why.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: lseek-compatmmap.patch --]
[-- Type: text/x-diff; name="lseek-compatmmap.patch", Size: 1527 bytes --]
commit 40ed0644ca8d250f716f49a5c3e027aa2c1d3167
Author: Alex Riesen <raa.lkml@gmail.com>
Date: Wed Nov 15 19:55:06 2006 +0100
Seek back to current filepos when mmap()ing with NO_MMAP, eh improved
"git-index-pack --fix-thin" relies on mmap() not changing the current
file position (otherwise the pack will be corrupted when writing the
final SHA1). Meet that expectation.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
diff --git a/compat/mmap.c b/compat/mmap.c
index 55cb120..c6d5cfe 100644
--- a/compat/mmap.c
+++ b/compat/mmap.c
@@ -6,7 +6,8 @@
void *gitfakemmap(void *start, size_t length, int prot , int flags, int fd, off_t offset)
{
- int n = 0;
+ int n = 0, err = 0;
+ off_t current_offset = lseek(fd, 0, SEEK_CUR);
if (start != NULL || !(flags & MAP_PRIVATE))
die("Invalid usage of gitfakemmap.");
@@ -18,8 +19,8 @@ void *gitfakemmap(void *start, size_t le
start = xmalloc(length);
if (start == NULL) {
- errno = ENOMEM;
- return MAP_FAILED;
+ err = ENOMEM;
+ goto unseek;
}
while (n < length) {
@@ -31,14 +32,22 @@ void *gitfakemmap(void *start, size_t le
}
if (count < 0) {
- free(start);
- errno = EACCES;
- return MAP_FAILED;
+ err = EACCES;
+ goto unseek;
}
n += count;
}
+unseek:
+ if (current_offset != lseek(fd, current_offset, SEEK_SET))
+ err = EINVAL;
+
+ if (err) {
+ free(start);
+ start = MAP_FAILED;
+ errno = err;
+ }
return start;
}
^ permalink raw reply related
* [PATCH] git-checkout: do not allow -f and -m at the same time.
From: Junio C Hamano @ 2006-11-15 19:06 UTC (permalink / raw)
To: git
Instead of silently ignoring one over the other, complain on
this incompatible combination.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* Back to fixing usability issues one at a time instead of
throwing everything away with bathwater.
git-checkout.sh | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/git-checkout.sh b/git-checkout.sh
index 119bca1..eb28b29 100755
--- a/git-checkout.sh
+++ b/git-checkout.sh
@@ -77,6 +77,11 @@ while [ "$#" != "0" ]; do
esac
done
+case "$force$merge" in
+11)
+ die "git checkout: -f and -m are incompatible"
+esac
+
# The behaviour of the command with and without explicit path
# parameters is quite different.
#
--
1.4.4
^ permalink raw reply related
* [PATCH] git-checkout: allow pathspec to recover lost working tree directory
From: Junio C Hamano @ 2006-11-15 19:07 UTC (permalink / raw)
To: git
It is often wanted on the #git channel that this were to work to
recover removed directory:
rm -fr Documentation
git checkout -- Documentation
git checkout HEAD -- Documentation ;# alternatively
Now it does.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* Back to fixing usability issues one at a time instead of
throwing everything away with bathwater.
git-checkout.sh | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/git-checkout.sh b/git-checkout.sh
index eb28b29..737abd0 100755
--- a/git-checkout.sh
+++ b/git-checkout.sh
@@ -112,7 +112,11 @@ Did you intend to checkout '$@' which ca
git-ls-tree --full-name -r "$new" "$@" |
git-update-index --index-info || exit $?
fi
- git-checkout-index -f -u -- "$@"
+
+ # Make sure the request is about existing paths.
+ git-ls-files --error-unmatch -- "$@" >/dev/null || exit
+ git-ls-files -- "$@" |
+ git-checkout-index -f -u --stdin
exit $?
else
# Make sure we did not fall back on $arg^{tree} codepath
--
1.4.4
^ permalink raw reply related
* Re: Cleaning up git user-interface warts
From: Marko Macek @ 2006-11-15 19:05 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Linus Torvalds, Junio C Hamano, git, cworth, pasky
In-Reply-To: <20061115184914.GA24122@spearce.org>
Shawn Pearce wrote:
> Nicolas Pitre <nico@cam.org> wrote:
>> As for the fraction of people complaining being a small fraction of
>> current GIT users: that is easily explainable by the fact that most
>> people who would have grown the complainers group are simply not GIT
>> users anymore since they were turned away by GIT's current user
>> interface issues. The only complainers remaining are those who see
>> value in the GIT technology but who would like to bring more
>> intuitiveness to the GIT interface instead of going for the alternative
>> technology. And those kind of people are always few.
>
> Or they are by proxy.
>
> *I* don't see that much of a problem with git pull; I can use it
> without trouble at this point. But I find it difficult to teach
> to others.
>
> My complaints about git pull/fetch/push are by proxy for about 10
> other users who aren't on the mailing list but whom I interact with
> through Git. They don't like pull/fetch/push very much.
>
> So count my complaints 10 times. :)
>
> Ok, that's still a drop in the bucket of current Git users.
> But still, I'm sure there are others. I think Carl was recently
> talking about complaints from some Fedora folks...
Agreed. Personally, the first thing that I notice when trying to switch
from Subversion to git is the behavior of 'index', mainly in git-diff, git-status and
git-commit.
For people switching from CVS and SVN it would be much better if the index was hidden
behind the scenes by using different defaults:
git-commit -a
git-status -a
git-diff HEAD
BTW, currently there's a minor bug: git-diff HEAD doesn't work before you
make the first commit. Perhaps this should be special cased.
I could personally get used to this, but I'd surely get blank
stares from people when teaching them the difference.
I guess this is the reason that the GIT Tutorial for CVS/SVN users is talking about _cogito_ instead.
(which is very confusing for someone coming to _git_ home page, trying to learn git).
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Andy Parkins @ 2006-11-15 19:14 UTC (permalink / raw)
To: git
In-Reply-To: <7vk61woar5.fsf@assigned-by-dhcp.cox.net>
On Wednesday 2006, November 15 17:55, Junio C Hamano wrote:
> I think the latter is what clone has done always; take remote's
> HEAD and use that to initialize local master (there is no
It's this sort of thing that is confusing though - the remote HEAD branch
could be anything, and yet that is made to be origin locally as a tracking
branch and then master as the writable branch. What if upstream /has/ a
master but "next" is its HEAD? You'd then get
next:remotes/origin
master:remotes/master
Then a local master which is actually upstream next! Oh dear.
I may well have misunderstood what you've said above above clone always
initialising master from remote's HEAD; if so please disregard what I'm
saying.
> > that as soon as git-clone has special capabilities (like --shared,
> > --local and --reference) then you are prevented from doing magic with
> > existing repositories.
>
> That is not entirely true. clone has convenience because people
> asked. It does not have to mean you are not allowed to give
> similar convenience to other commands. Patches?
Absolutely, that was why I said clone shouldn't have special abilities. In
fact, if you're willing you don't need clone at all; you just need
git-init-db and to write the correct remotes file.
> > branches from two other local repositories that have the objects hard
> > linked?
>
> fetch by second local repository with git-local-fetch perhaps.
Is that not plumbing? I thought this was about porcelain.
> A consensus would not write code and it generally does not take
> technology into account to tell what is realistic and what is
> not, so the result needs to be take with a grain of salt,
> though.
Of course, I only suggested it because the same suggestions were popping up
multiple times. Anyway; I put it in the GitWiki at
http://git.or.cz/gitwiki/Wishlist
Andy
--
Dr Andrew Parkins, M Eng (Hons), AMIEE
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Linus Torvalds @ 2006-11-15 19:18 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200611151858.51833.andyparkins@gmail.com>
On Wed, 15 Nov 2006, Andy Parkins wrote:
>
> On the one hand you're arguing that git syntax is easy to learn, and on the
> other that no one will be able to learn a new syntax just as easily.
I'm saying that people who are new to git will _have_ to learn new
concepts ANYWAY.
I don't think the naming is the hard part.
The fact is, git is one of the very few (essentially _only_) SCM's that
make it very clear that all real operations are local and that if you want
to work with other repositories, you have to "fetch" those into local
branches first. The fact that "pull" exists at all is really just
shorthand.
If people have trouble explaining this to others, and have trouble
grasping "pull", then I will bet that the _real_ issue has nothing at all
to do with naming at all, and the real issue is that people are being
_taught_ the concepts in the wrong order.
Before you learn "pull", you should learn "fetch". Don't even _mention_
"pull" until the person got what "fetch" means. Because the fact is,
"fetch" is really the much more fundamental operation, and once you
really understand what "fetch" does, "pull" is obvious.
So I'll argue that the problem isn't naming, the "problem" is really that
git has a few fundamnetal concepts that people aren't used to. The most
fundamnetal of those is the notion of the local branch-space. EVERY other
(broken) SCM has branches as being some kind of totally idiotic separate
subdirectories, or doesn't really support branches at all (ie neither BK
nor CVS really support "branches" - even if a concept of that name exists
in CVS, it has nothing at all in common with the git model of branches).
But once you understand branches, and understand "fetch" (and it really
isn't _that_ complicated: fetch really does exactly what the name says, so
if you understand local branches, you will understand "fetch"), then it's
a much smaller step to explain "pull = fetch + merge".
But I bet people don't teach it that way. They _start_ by teaching "pull".
Right?
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Junio C Hamano @ 2006-11-15 19:32 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200611151858.51833.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> writes:
>> But trying to rename "pull" (or the "git" name itself) is just going to
>> cause more confusion than you fix.
>
> I don't think so. Mainly because the proposed new git pull would be a subset
> of the existing git pull. It's not changing function, it's just reducing in
> function.
We usually use the word "regression" to refer to that kind of
change.
I think it makes a lot of sense having command x that does
essentially the same thing as the current fetch but with more
usability enhancements and more convention as built-in defaults,
and another command y that does what the current 'pull .' does
but with more usability enhancements and more convention as
built-in defaults. I agree that kind of UI improvements would
make it easier to explain to new people. Calling x "pull",
however, breaks the existing users and documents, and causes
confusion. I really do not think you can argue with that.
That's why we are talking about using an uncontaminated word
"get". I think it is a good effort.
>> aren't that complicated. There's no reason to rename them. We do have
>> other problems:
>
> That there are other problems doesn't negate these problems.
And I think Linus is right in pointing out that there are other
problems that are equally or even more pressing than _renaming_
to break things for existing users.
I personally do not think the current fetch/pull confusing, and
I do see real downside in _renaming_ them, but I am open to the
current get/put discussion because I think the new commands'
semantics may be designed to match newcomers' expectation better
(it's to match tools to newcomers instead of teaching them the
new language of the land) and I do not think that approach would
break existing users and documents.
For some things "matching tools to newcomers" would not really
work, though. For example, I do not think you can get away with
hiding index forever if you want your users to do real work in a
workflow that involves merging and cherry picking.
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Michael K. Edwards @ 2006-11-15 19:39 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0611151111250.3349@woody.osdl.org>
On 11/15/06, Linus Torvalds <torvalds@osdl.org> wrote:
> But once you understand branches, and understand "fetch" (and it really
> isn't _that_ complicated: fetch really does exactly what the name says, so
> if you understand local branches, you will understand "fetch"), then it's
> a much smaller step to explain "pull = fetch + merge".
>
> But I bet people don't teach it that way. They _start_ by teaching "pull".
> Right?
"git fetch" is certainly the right thing for the platform integration
role, in which one is trying to maintain a series of integration
branches which track the bleeding edge of some subsystems while
keeping the core stable on each branch. This is not as impossible as
people make it out to be, but there certainly isn't much place for
automatic merges to _persistent_ branches.
It's fundamentally a backporting and cherry-picking effort, and the
git workflow puts it where it belongs: in the local repository, where
_transient_ branches can and should be created and destroyed casually
to track exploratory efforts. These may include automatic merges and
even cruder techniques (git diff, hack on patch, apply patch). Once
you figure out which bits you actually want to backport, you go back
to a fresh branch and cherry-pick the same bits with the tool instead
of manually, so that there is less noise in future merges. When
you've tested a little, you merge this branch to the persistent branch
that other repositories track.
Cheers,
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Junio C Hamano @ 2006-11-15 19:41 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200611151902.16358.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> writes:
> On Wednesday 2006, November 15 18:16, Junio C Hamano wrote:
>
>> I still think in the long run you would be better off giving
>> separate names to Porcelains because I am sure you are going to
>
> The problem I think with that is that the line between plumbing and porcelain
> is not clear.
This is moot because we (at least tentatively) agreed not to do
"gh" or "ig" or whatever, but I do not understand why you feel
so.
If we had a separate Porcelain namespace (say "ng" for "new
git") you would know "ng-commit" is not a Plumbing and when you
are writing a Porcelain script you would stay away from using it
in your script.
In the longer term, when the new Porcelain UI Nico and friends
are designing matures, and if it makes everybody (including
existing users who learned git-* Porcelain-ish during 18-months
process) happy, we could gradually deprecate and eventually
remove the git-* Porcelain-ish over time, at that point we would
have a very clear line between plumbing and porcelain.
But that would not be a flag-day change. During the transition
period you cannot mechanically tell if git-foo is a plumbing or
a porcelain just like you cannot do so now.
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Linus Torvalds @ 2006-11-15 20:09 UTC (permalink / raw)
To: Michael K. Edwards; +Cc: git
In-Reply-To: <f2b55d220611151139v66fba16ax97ce6b9966b33ce7@mail.gmail.com>
On Wed, 15 Nov 2006, Michael K. Edwards wrote:
> >
> > But I bet people don't teach it that way. They _start_ by teaching "pull".
> > Right?
>
> "git fetch" is certainly the right thing for the platform integration
> role
I'm saying that even if you _never_ end up using "git fetch" ever again
(because in practice you always want to do a "fetch + merge == pull"),
people who teach others the concepts and usage of git should probably
start by talking about "git fetch".
Then, when the user says (and he obviously will say this) "but I don't
want to just fetch the other persons work into some local branch, I want
to actually get it into _my_ branch", you say "Ahhah!" and talk about how
"pull" is a shorthand for first fetching and then merging the result into
the current branch.
See? Once you explain "fetch" to somebody, I can pretty much guarantee
that they'll explain "pull" to themselves without you having to even work
at it. And then they'll probably happily use "pull" ever after, and never
worry about fetch, but now they'll understand the _concepts_.
It's only if you start the other way around that "pull" vs "fetch" vs
"push" become confusing. If you _start_ by explaining branches (and you
might use "gitk --all" on a small project as a visualization tool),
suddenly the concepts aren't all that complicated.
Sure, then you have to remember two words ("pull" vs "fetch"), but I'm
pretty sure that the thing that makes people confused is not the words
themselves, but their lack of understanding of the concepts behind them.
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Petr Baudis @ 2006-11-15 20:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, git
In-Reply-To: <7v3b8ltq7r.fsf@assigned-by-dhcp.cox.net>
On Wed, Nov 15, 2006 at 03:10:16AM CET, Junio C Hamano wrote:
> You have to admit both pull and fetch have been contaminated
> with loaded meanings from different backgrounds. I was talking
> about killing the source of confusion in the longer term by
> removing fetch/pull/push, so we are still on the same page.
How was/is fetch contaminated?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Nicolas Pitre @ 2006-11-15 20:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andy Parkins, git
In-Reply-To: <7vr6w4lcpr.fsf@assigned-by-dhcp.cox.net>
On Wed, 15 Nov 2006, Junio C Hamano wrote:
> If we had a separate Porcelain namespace (say "ng" for "new
> git") you would know "ng-commit" is not a Plumbing and when you
> are writing a Porcelain script you would stay away from using it
> in your script.
There is merit in trying to segregate porcelain vs plumbing... at least
in theory. In practice though I don't think this is something we should
absolutely strive for.
Why? Because something is always going to fail the categorization.
Sure there are commands that are pure plumbing like git-commit-tree,
etc. Some are pure porcelain like git-commit or git-log. Yet we use
git-log's output for git-shortlog. Does it mean that git-log is
plumbing? Also I have a script here that uses git-commit directly
because it is so much convenient rather than futzing with the really
bare plumbing. I don't think git-commit should be prevented from being
used within another script even if it is classified as porcelain.
So we have that notion of plumbing vs porcelain but in practice there is
a whole spectrum between those two poles and I think it is a good thing.
^ permalink raw reply
* [PATCH] Run "git repack -a -d" once more at end, if there's 1MB or more of not-packed data.
From: Jim Meyering @ 2006-11-15 20:15 UTC (permalink / raw)
To: git
Although I converted upstream coreutils to git last month, I just
reconverted coreutils once again, as a test, and ended up with a
git repository of about 130MB (contrast with my packed git repo of
size 52MB). That was because there were a lot of commits (but < 1024)
after the final automatic "git-repack -a -d".
Running a final
git-repack -a -d && git-prune-packed
cut the final repository size down to the expected size.
So this looks like an easy way to improve git-cvsimport.
Just run "git repack ..." at the end if there's more than
some reasonable amount of not-packed data.
My choice of 1MB is a little arbitrarily. I wouldn't mind missing
the minimal repo size by 1MB. At the other end of the spectrum,
it's probably not worthwhile to pack everything when the total
repository size is less than 1MB.
Here's the patch:
Signed-off-by: Jim Meyering <jim@meyering.net>
---
git-cvsimport.perl | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index 14e2c61..b54a948 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -876,6 +876,16 @@ while(<CVS>) {
}
commit() if $branch and $state != 11;
+# The heuristic of repacking every 1024 commits can leave a
+# lot of unpacked data. If there is more than 1MB worth of
+# not-packed objects, repack once more.
+my $line = `git-count-objects`;
+if ($line =~ /^(\d+) objects, (\d+) kilobytes$/) {
+ my ($n_objects, $kb) = ($1, $2);
+ 1024 < $kb
+ and system("git repack -a -d");
+}
+
foreach my $git_index (values %index) {
if ($git_index ne '.git/index') {
unlink($git_index);
--
^ permalink raw reply related
* Re: Cleaning up git user-interface warts
From: Carl Worth @ 2006-11-15 20:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andy Parkins, git
In-Reply-To: <7vr6w4lcpr.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 1996 bytes --]
On Wed, 15 Nov 2006 11:41:20 -0800, Junio C Hamano wrote:
> Andy Parkins <andyparkins@gmail.com> writes:
> > On Wednesday 2006, November 15 18:16, Junio C Hamano wrote:
> >
> >> I still think in the long run you would be better off giving
> >> separate names to Porcelains because I am sure you are going to
> >
> > The problem I think with that is that the line between plumbing and porcelain
> > is not clear.
>
> This is moot because we (at least tentatively) agreed not to do
> "gh" or "ig" or whatever, but I do not understand why you feel
> so.
I'm not the original poster, but I feel the same way about the line
being unclear.
Here's a real-world example from last week.
For cairo I wrote a little script that two revspecs, (or one in
which case its first parent is used), and it goes off and checks out
both versions, builds each, runs a performance test on each, and then
generates a report showing the performance impact.
So now I can do things like:
# What's the performance impact of my latest change:
cairo-perf-diff HEAD
# Have my last few changes helped as much as I'd hoped:
cairo-perf-diff HEAD~3 HEAD
# How has performance changed since our last stable release:
cairo-perf-diff 1.2.6 HEAD
Anyway, when I announced this I also mentioned how easily someone
might generate an entire series of reports for a series of
commits. The command I gave as an example is:
for rev in $(git rev-list 1.2.6..HEAD); do
cairo-perf-diff $rev
done
I think that's a perfectly legitimate one-liner for users to use, and
it really shows off the easy-scriptability of git. But certainly, no
"new porcelain" author is going to consider rev-list to be porcelain
rather than plumbing, right? So as soon as I start teaching people to
do useful stuff like this, they might have to reach down into the
"scary" git interface.
I think we're much better off just having one "git" namespace for the
standard command-line interface, and then making it as easy to use as
possible.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Nicolas Pitre @ 2006-11-15 20:21 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Michael K. Edwards, git
In-Reply-To: <Pine.LNX.4.64.0611151203450.3349@woody.osdl.org>
On Wed, 15 Nov 2006, Linus Torvalds wrote:
> I'm saying that even if you _never_ end up using "git fetch" ever again
> (because in practice you always want to do a "fetch + merge == pull"),
> people who teach others the concepts and usage of git should probably
> start by talking about "git fetch".
>
> Then, when the user says (and he obviously will say this) "but I don't
> want to just fetch the other persons work into some local branch, I want
> to actually get it into _my_ branch", you say "Ahhah!" and talk about how
> "pull" is a shorthand for first fetching and then merging the result into
> the current branch.
Actually I believe it would make things even clearer if "merge" was
taught at that point. Only when the user is comfortable with the
separate notions of fetching and merging might the pull shorthand
possibly be mentioned.
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Nicolas Pitre @ 2006-11-15 20:26 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20061115201227.GM7201@pasky.or.cz>
On Wed, 15 Nov 2006, Petr Baudis wrote:
> On Wed, Nov 15, 2006 at 03:10:16AM CET, Junio C Hamano wrote:
> > You have to admit both pull and fetch have been contaminated
> > with loaded meanings from different backgrounds. I was talking
> > about killing the source of confusion in the longer term by
> > removing fetch/pull/push, so we are still on the same page.
>
> How was/is fetch contaminated?
I think "fetch" is sane. Its only problem is a missing symetrical
counterpart verb, like "get" and "put".
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Josef Weidendorfer @ 2006-11-15 20:31 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Linus Torvalds, Nicolas Pitre, Junio C Hamano
In-Reply-To: <ejfm6c$bu4$1@sea.gmane.org>
On Wednesday 15 November 2006 19:28, you wrote:
> Linus Torvalds wrote:
>
> > But the fact is, git isn't really that hard to work out, and the commands
> > aren't that complicated. There's no reason to rename them. We do have
> > other problems:
> >
> > - default branch selection for merging is broken (it should definitely
> > take the current branch into account). When I do "git pull" with no
> > branch specification, and I happen to be on a branch that is associated
> > with something else than "master" in the remote, I shouldn't merge with
> > master.
>
> This problem is _slightly_ migitated by branch.<name>.merge config variable.
> Slightly because you have to specify branch to merge, instead of forbidding
> merge if you are not on specific branch (and you don't override it).
We should change this.
The problem is that whatever is the first Pull line in remotes config gets
merged by default into current branch, which most often is not the right
thing to do.
Often, I find myself doing "git branch" just to make sure that I am on
"master", so that a following pull does not do a bogus merge.
Can we please disable this behavior, e.g. by allowing a fake first
Pull line like "Pull: (not-for-merge)" to prohibit any merge?
This even could be written by default in git-clone somewhere in the future,
and we suddenly get the behavior of pull being symmetric to push - at least
by default. And still, it is fully compatible to existing repositories.
To make pull do the right thing, we _have_ to configure branch.<name>.merge
whenever we create a new branch (which matters for git-clone, too).
Josef
>
> > - I agree that having to create temporary branches to just look at a tag
> > that you don't want to actually develop on is just unnecessarily
> > bothersome.
>
> Agreed.
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Petr Baudis @ 2006-11-15 20:35 UTC (permalink / raw)
To: Josef Weidendorfer
Cc: Jakub Narebski, git, Linus Torvalds, Nicolas Pitre,
Junio C Hamano
In-Reply-To: <200611152131.14883.Josef.Weidendorfer@gmx.de>
On Wed, Nov 15, 2006 at 09:31:13PM CET, Josef Weidendorfer wrote:
> Often, I find myself doing "git branch" just to make sure that I am on
> "master", so that a following pull does not do a bogus merge.
>
> Can we please disable this behavior, e.g. by allowing a fake first
> Pull line like "Pull: (not-for-merge)" to prohibit any merge?
Wait, if you don't want pull to merge, why do you pull and not fetch?
(Disclaimer: I'm not intimately familiar with git pull/fetch and I
didn't read the whole thread yet.)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply
* [PATCH] gitweb: Put back shortlog instead of graphiclog in the project list.
From: Alexandre Julliard @ 2006-11-15 20:37 UTC (permalink / raw)
To: git
Looks like a repo.or.cz-specific change slipped in.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
---
gitweb/gitweb.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index e54a29e..7587595 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2454,7 +2454,7 @@ sub git_project_list_body {
$pr->{'age_string'} . "</td>\n" .
"<td class=\"link\">" .
$cgi->a({-href => href(project=>$pr->{'path'}, action=>"summary")}, "summary") . " | " .
- $cgi->a({-href => '/git-browser/by-commit.html?r='.$pr->{'path'}}, "graphiclog") . " | " .
+ $cgi->a({-href => href(project=>$pr->{'path'}, action=>"shortlog")}, "shortlog") . " | " .
$cgi->a({-href => href(project=>$pr->{'path'}, action=>"log")}, "log") . " | " .
$cgi->a({-href => href(project=>$pr->{'path'}, action=>"tree")}, "tree") .
($pr->{'forks'} ? " | " . $cgi->a({-href => href(project=>$pr->{'path'}, action=>"forks")}, "forks") : '') .
--
1.4.4.g2e5b
--
Alexandre Julliard
^ permalink raw reply related
* Re: Cleaning up git user-interface warts
From: Petr Baudis @ 2006-11-15 20:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd57ps51c.fsf@assigned-by-dhcp.cox.net>
On Wed, Nov 15, 2006 at 05:33:03AM CET, Junio C Hamano wrote:
> Petr Baudis <pasky@suse.cz> writes:
> > (v) Git would be properly libified by now. If you wanted to convert
> > bits of porcelain to C, it would be at least much higher priority.
>
> I am not sure about "libified" part and I do not know what bits
> of porcelain wants to become C right now. But I do not think
> this point is important part of your list.
Merge strategies. Or wait, is that already plumbing?
Or git-status. git-add. Plenty more.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Linus Torvalds @ 2006-11-15 20:40 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Michael K. Edwards, git
In-Reply-To: <Pine.LNX.4.64.0611151516360.2591@xanadu.home>
On Wed, 15 Nov 2006, Nicolas Pitre wrote:
>
> Actually I believe it would make things even clearer if "merge" was
> taught at that point. Only when the user is comfortable with the
> separate notions of fetching and merging might the pull shorthand
> possibly be mentioned.
I agree. I just expect that "merge" is such a simple concept that it
doesn't really need a whole lot of explaining.
People kind of expect merging to be hard, but I think it's because CVS et
al have tought people that merging is _painful_. I don't think it's a very
complicated concept per se, especially if you have explained branches with
gitk already.
But yes, the order should be:
(a) explain what "branches" mean in git (and in that situation, "fetch"
is very natural - I think fetching itself is probably easier to
explain than "branches" are).
(b) once you've explained branches, the notion of "merge" comes next, and
I _think_ that is very obvious. This is where UI issues come in,
because "git merge" is really a totally internal program with a
pretty horrid UI, but I think we could fix the syntax, and even with
the current syntax you can really just gloss it over, because nobody
is really going to care.
(c) once "fetching branches" and "merging" have been explained, "pull" is
really pretty damn trivial, and in fact, if you then explain that
it's just easier to do "git pull . branchname" than to use "git
merge", I think people may just even agree with you.
I think I saw that particular discussion on #git: somebody didn't expect
"git pull . branch" to be the way to merge. And again, I think it's
not _really_ because "pull" is hard to understand, it's because people
haven't been walked through the thing in this way.
Once you understand local branches, fetching and merging, it's actually
_easier_ to explain why we merge even local branches with "git pull .":
you just tell them that this way you can use the same command regardless
of whether you're merging something local or something remote. Again, if
it's explained that way, I bet a lot of people react with "ahh, that's
clever", and _like_ the fact that they only really need to learn _one_
command, instead of learning two.
See? Explain it that way: "pull" really is simple. By using "pull", you
don't have to learn about "merge" syntax. You -can- use "merge" as a
separate program if you want to, but the syntax isn't very nice, exactly
because you're not really expected to.
But the real issue here is to explain local branches. I will happily admit
that local branches are very VERY different from just about any other SCM,
but I also claim that git is just much BETTER than other SCM's in this
respect.
And yes, this is why you should NOT try to use the same naming as "hg",
for example. Last I saw, hg still didn't even have local branches, To
mercurial, repository == branch, and that's it. It was what I came from
too, and I used to argue for using git that way too. I've since seen the
error of my ways, and git is simply BETTER.
And the concept of local branches is exactly _why_ you have to have
separate "fetch" and "pull", but why you do _not_ need a separate "merge"
(because "pull ." does it for you).
If you don't understand local branches, you'll never understand git usage.
And once you _do_ understand local branches, "fetch" vs "pull" actually is
rather simple.
^ 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