* Re: git on afs
From: Linus Torvalds @ 2007-10-19 19:06 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Todd T. Fries, git
In-Reply-To: <20071019060624.GK14735@spearce.org>
On Fri, 19 Oct 2007, Shawn O. Pearce wrote:
>
> What about this instead? It avoids the double lstat() of Todd's
> original patch but seems like it would fix the issue here. Or did
> I misunderstand the problem?
No. As far as I can tell without testing it, this patch will make it show
ignored regular files if they have DT_UNKNOWN in the directory entry (or
the filesystem doesn't support it). Not good.
Linus
^ permalink raw reply
* Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'
From: Linus Torvalds @ 2007-10-19 19:00 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jeff King, Shawn O. Pearce, git
In-Reply-To: <alpine.LFD.0.9999.0710190753040.19446@xanadu.home>
On Fri, 19 Oct 2007, Nicolas Pitre wrote:
> On Fri, 19 Oct 2007, Jeff King wrote:
> >
> > Ah, right. I hadn't thought of that. While it would be a nice
> > convenience feature, it's probably not worth the deep internal hackery
> > that would be required.
>
> What about a preprocessor that could match <1>@{<2>..<3>} in the
> argument list and substitute that with <1>@{<2>}..<1>@{<3>} before it is
> actually parsed?
Could be done, but I almost think it would be better to just make the
sha1_name.c interfaces take some extended data structure which allows
looking up multiple SHA1's at the same time.
Sure, we'd leave the "simple" interfaces around for users that simply want
just one SHA1 value, but that would allow us to remove duplicate code from
revision.c and rev-parse.c. And it would allow us to generally make the
SHA1 parsing fancier: there may well be other expressions that are worth
doing.
Linus
^ permalink raw reply
* Re: [RFC/PATCH] git-fetch: mega-terse fetch output
From: Nicolas Pitre @ 2007-10-19 18:51 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Steven Grimm, Shawn O. Pearce, David Symonds, Jeff King, git
In-Reply-To: <20071019172610.GE30825@uranus.ravnborg.org>
On Fri, 19 Oct 2007, Sam Ravnborg wrote:
> On Fri, Oct 19, 2007 at 12:12:41PM -0400, Nicolas Pitre wrote:
> > This is even more wrong.
> >
> > Agreed, indexing objects might not be the best description. It probably
> > will become "receiving objects" along with a bandwitth meter.
>
> The term 'objects' here always confuses me. What is often my first
> thing to check the number of individual commits being added after
> a git pull. Wether a commit touches one or several files is less
> important (to my way of using git).
Let me unconfuse you.
Git storage is made of, well, objects. You might think that objects are
related to the number of files concerned by a set of commits during a
pull, but this is not the case. It is well possible to have a commit
touching 100 files and have much fewer new objects created than that.
Reverting a patch, for example, would only restore a reference to older
objects in the database. The same is true if you move an entire
directory around.
The opposite is also true: you can have more new objects than modified
files for a single commit, depending on the directory depth.
So the number of objects has no exact relationship what so ever with the
number of objects. However the number of objects has a much more direct
influence on the time to perform a fetch, and that is what we're
displaying here. After all when you issue a pull and wait for it to
complete, you wait for X amount of objects to be transferred and not Y
amount of commits.
The important metric is therefore measured in "objects". But you're
free to ignore it and only look at the percentage if you prefer.
Nicolas
^ permalink raw reply
* RE: git push bug?
From: Joakim Tjernlund @ 2007-10-19 18:50 UTC (permalink / raw)
To: 'Johannes Schindelin'; +Cc: 'Steffen Prohaska', 'git'
In-Reply-To: <Pine.LNX.4.64.0710191920210.16728@wbgn129.biozentrum.uni-wuerzburg.de>
> -----Original Message-----
> From: Johannes Schindelin [mailto:Johannes.Schindelin@gmx.de]
> Sent: den 19 oktober 2007 19:25
> To: Joakim Tjernlund
> Cc: Steffen Prohaska; git
> Subject: Re: git push bug?
>
> Hi,
>
> On Fri, 19 Oct 2007, Joakim Tjernlund wrote:
>
> > On Thu, 2007-10-18 at 23:00 +0100, Johannes Schindelin wrote:
> > >
> > > On Thu, 18 Oct 2007, Joakim Tjernlund wrote:
> > >
> > > > First, I didn't know that I could do that. Secondly, I was also
> > > > looking do v2.6.23:linus refspecs
> > >
> > >
> > > First, then our documentation could be better. How?
> >
> > Well, it isn't clear to me how all this is supposed to work
> and what is
> > bugs. Clearifying that would help.
> >
> > For instances I did a push with v2.6.23:refs/heads/linus
> and now I got a
> > branch with the SHA1 of v2.6.23
> > tag(0b8bc8b91cf6befea20fe78b90367ca7b61cfa0d) in it. Makes
> gitk display
> > that branch as "linus^{}".
>
> It strikes me as really odd that you would _want_ to create a branch
> remotely, that has _never_ existed locally.
It strikes me as really odd that a core developers like yourself
hasn't tried to justify/explain why push works as it does.
As I am trying to convince our dev. group here to move to git instead of subversion, I
need to learn how git works. Now I have gotten to the push function and I need
to know what can be done with push and how, pitfalls too. As I go along I find behavior
that I find odd and report these to the list.
git push <repo> v2.6.23:refs/heads/linus
will make a tag look like a branch
git push <repo> linus:linus
won't let me create the remote branch linus but
git push <repo> linus
will
git push <repo> :linus
OOPS, now I just deleted remote branch linus, no warning
git push <repo> linus:refs/head/linus
creates a branch that is invisible(wont show in git branch -a)
git push <repo> linus:refs/heads/newbranch
creates remote branch newbranch, but you have to know the magic words
refs/heads/ to do it.
Se what I mean?
>
> > > Second, why not "git checkout -b linus v2.6.23 && git push origin
> > > linus"?
> >
> > An extra checkout that takes time but works.
>
> Not only that: before trying to publish something, I would
> have expected
> you to have that branch locally, and that you actually worked on it.
>
> > Doesn't make the above "weiredness" go away though.
>
> Yes it does.
No it doesn't. If someone else in my group wants to create a branch they
might do the same mistakes as I did.
>
> git checkout -b <branchname> resolves to the commit that the
> tag pointed
> to. So it would not push a tag, which you did.
>
> Of course you could do what you planned to do, if you knew
> git better.
> But you are not familiar enough with git's inner workings yet, so I
> suggest to stay with things for now that work _always_, and
> exactly as
> expected.
>
> Such as creating a branch locally, with exactly the name that
> you plan it
> to have remotely, and then pushing it with "git push origin
> <branchname>".
> Easy as apple pie.
>
> Ciao,
> Dscho
>
>
>
^ permalink raw reply
* Re: git on afs
From: Linus Torvalds @ 2007-10-19 17:59 UTC (permalink / raw)
To: Todd T. Fries; +Cc: git, Shawn O. Pearce, Brandon Casey
In-Reply-To: <200710190719.21660.todd@fries.net>
On Fri, 19 Oct 2007, Todd T. Fries wrote:
>
> If DT_UNKNOWN exists, then we have to do a stat() of some form to
> find out the right type.
>
> This is difficult to fix properly to avoid the extra stat() since
> inside the switch logic we do the recursion, but we might have
> avoided it earlier because of the exclusion.
>
> I'll send a separate diff for an updated link() vs rename() diff.
>
> I've attached an updated diff that should address concerns of everyone
> who gave me feedback on my dir.c changes.
>
> Better?
Yes. I think this is ok, although I also did this alternate patch that is
anal about not bothering to call "lstat()" if it can decide that the path
is ignored even before that.
That happened in the case of a pathname that was ignored, and we did not
ask for "dir->show_ignored". That test used to be *together* with the
"DTYPE(de) != DT_DIR", but splitting the two tests up means that we can do
that (common) test before we even bother to calculate the real dtype.
Of course, that optimization only matters for systems that don't have, or
don't fill in DTYPE properly, but I get a bit anal about these kinds of
optimizations.
I also clarified the real relationship between "exclude" and
"dir->show_ignored". It used to do
if (exclude != dir->show_ignored) {
..
which wasn't exactly obvious, because it triggers for two different cases:
- the path is marked excluded, but we are not interested in ignored
files: ignore it
- the path is *not* excluded, but we *are* interested in ignored files:
ignore it unless it's a directory, in which case we might have ignored
files inside the directory and need to recurse into it).
so this splits them into those two cases, since the first case doesn't
even care about the type.
I also made a the DT_UNKNOWN case a separate helper function, and added
some commentary to the cases.
Does this patch work for you?
Linus
---
dir.c | 52 ++++++++++++++++++++++++++++++++++++++--------------
1 files changed, 38 insertions(+), 14 deletions(-)
diff --git a/dir.c b/dir.c
index eb6c3ab..f843c4d 100644
--- a/dir.c
+++ b/dir.c
@@ -443,6 +443,24 @@ static int in_pathspec(const char *path, int len, const struct path_simplify *si
return 0;
}
+static int get_dtype(struct dirent *de, const char *path)
+{
+ int dtype = DTYPE(de);
+ struct stat st;
+
+ if (dtype != DT_UNKNOWN)
+ return dtype;
+ if (lstat(path, &st))
+ return dtype;
+ if (S_ISREG(st.st_mode))
+ return DT_REG;
+ if (S_ISDIR(st.st_mode))
+ return DT_DIR;
+ if (S_ISLNK(st.st_mode))
+ return DT_LNK;
+ return dtype;
+}
+
/*
* Read a directory tree. We currently ignore anything but
* directories, regular files and symlinks. That's because git
@@ -466,7 +484,7 @@ static int read_directory_recursive(struct dir_struct *dir, const char *path, co
exclude_stk = push_exclude_per_directory(dir, base, baselen);
while ((de = readdir(fdir)) != NULL) {
- int len;
+ int len, dtype;
int exclude;
if ((de->d_name[0] == '.') &&
@@ -486,24 +504,30 @@ static int read_directory_recursive(struct dir_struct *dir, const char *path, co
if (exclude && dir->collect_ignored
&& in_pathspec(fullname, baselen + len, simplify))
dir_add_ignored(dir, fullname, baselen + len);
- if (exclude != dir->show_ignored) {
- if (!dir->show_ignored || DTYPE(de) != DT_DIR) {
+
+ /*
+ * Excluded? If we don't explicitly want to show
+ * ignored files, ignore it
+ */
+ if (exclude && !dir->show_ignored)
+ continue;
+
+ dtype = get_dtype(de, fullname);
+
+ /*
+ * Do we want to see just the ignored files?
+ * We still need to recurse into directories,
+ * even if we don't ignore them, since the
+ * directory may contain files that we do..
+ */
+ if (!exclude && dir->show_ignored) {
+ if (dtype != DT_DIR)
continue;
- }
}
- switch (DTYPE(de)) {
- struct stat st;
+ switch (dtype) {
default:
continue;
- case DT_UNKNOWN:
- if (lstat(fullname, &st))
- continue;
- if (S_ISREG(st.st_mode) || S_ISLNK(st.st_mode))
- break;
- if (!S_ISDIR(st.st_mode))
- continue;
- /* fallthrough */
case DT_DIR:
memcpy(fullname + baselen + len, "/", 2);
len++;
^ permalink raw reply related
* [PATCH] git-cherry-pick: improve description of -x.
From: Ralf Wildenhues @ 2007-10-19 17:41 UTC (permalink / raw)
To: git
Reword the first sentence of the description of -x, in order to
make it easier to read and understand.
Signed-off-by: Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
---
I have two issues with "git-cherry-pick -x": When reading its manpage
description for the first time, I completely failed to understand the
first sentence, and had to try it out in order to understand.
Further, I am surprised that -x seems to be nonfunctional when the
cherry pick introduces a conflict. Example:
git init
echo >dummy
git add dummy
git commit -m dummy
git checkout -b br
echo one >file
git add file
git commit -m one
echo two >>file
git commit -a -m two
git checkout master
git cherry-pick -x br # conflict, tells me "-c ..." arg to use
# for the commit later
echo '1d
w' | ed file # resolve conflict
git add file
git commit -c ...
The prototype commit message now does not contain the
| (cherry picked from commit ...).
Is that by design (because there were conflicts) or an omission?
In case of the former, maybe the description of -x should mention this.
Thanks,
Ralf
Documentation/git-cherry-pick.txt | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-cherry-pick.txt b/Documentation/git-cherry-pick.txt
index 47b1e8c..c7d83ce 100644
--- a/Documentation/git-cherry-pick.txt
+++ b/Documentation/git-cherry-pick.txt
@@ -27,10 +27,10 @@ OPTIONS
message prior committing.
-x::
- Cause the command to append which commit was
- cherry-picked after the original commit message when
- making a commit. Do not use this option if you are
- cherry-picking from your private branch because the
+ When recording the commit, the original commit message will
+ be appended with a note that indicates which commit this
+ change was cherry-picked from. Do not use this option if
+ you are cherry-picking from your private branch because the
information is useless to the recipient. If on the
other hand you are cherry-picking between two publicly
visible branches (e.g. backporting a fix to a
--
1.5.3.1.153.g89df5
^ permalink raw reply related
* [PATCH] gitk.txt: Fix markup.
From: Ralf Wildenhues @ 2007-10-19 17:24 UTC (permalink / raw)
To: git
For the manpage, avoid generating an em dash in code.
Signed-off-by: Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
---
Documentation/gitk.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/gitk.txt b/Documentation/gitk.txt
index e9f82b9..8dbfb0d 100644
--- a/Documentation/gitk.txt
+++ b/Documentation/gitk.txt
@@ -69,7 +69,7 @@ gitk --since="2 weeks ago" \-- gitk::
The "--" is necessary to avoid confusion with the *branch* named
'gitk'
-gitk --max-count=100 --all -- Makefile::
+gitk --max-count=100 --all \-- Makefile::
Show at most 100 changes made to the file 'Makefile'. Instead of only
looking for changes in the current branch look in all branches.
--
1.5.3.1.153.g89df5
^ permalink raw reply related
* Re: git push bug?
From: Johannes Schindelin @ 2007-10-19 17:24 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: Steffen Prohaska, git
In-Reply-To: <1192805255.1875.25.camel@gentoo-jocke.transmode.se>
Hi,
On Fri, 19 Oct 2007, Joakim Tjernlund wrote:
> On Thu, 2007-10-18 at 23:00 +0100, Johannes Schindelin wrote:
> >
> > On Thu, 18 Oct 2007, Joakim Tjernlund wrote:
> >
> > > First, I didn't know that I could do that. Secondly, I was also
> > > looking do v2.6.23:linus refspecs
> >
> >
> > First, then our documentation could be better. How?
>
> Well, it isn't clear to me how all this is supposed to work and what is
> bugs. Clearifying that would help.
>
> For instances I did a push with v2.6.23:refs/heads/linus and now I got a
> branch with the SHA1 of v2.6.23
> tag(0b8bc8b91cf6befea20fe78b90367ca7b61cfa0d) in it. Makes gitk display
> that branch as "linus^{}".
It strikes me as really odd that you would _want_ to create a branch
remotely, that has _never_ existed locally.
> > Second, why not "git checkout -b linus v2.6.23 && git push origin
> > linus"?
>
> An extra checkout that takes time but works.
Not only that: before trying to publish something, I would have expected
you to have that branch locally, and that you actually worked on it.
> Doesn't make the above "weiredness" go away though.
Yes it does.
git checkout -b <branchname> resolves to the commit that the tag pointed
to. So it would not push a tag, which you did.
Of course you could do what you planned to do, if you knew git better.
But you are not familiar enough with git's inner workings yet, so I
suggest to stay with things for now that work _always_, and exactly as
expected.
Such as creating a branch locally, with exactly the name that you plan it
to have remotely, and then pushing it with "git push origin <branchname>".
Easy as apple pie.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC/PATCH] git-fetch: mega-terse fetch output
From: Sam Ravnborg @ 2007-10-19 17:26 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Steven Grimm, Shawn O. Pearce, David Symonds, Jeff King, git
In-Reply-To: <alpine.LFD.0.9999.0710191211210.19446@xanadu.home>
On Fri, Oct 19, 2007 at 12:12:41PM -0400, Nicolas Pitre wrote:
> On Fri, 19 Oct 2007, Steven Grimm wrote:
>
> > On 19/10/2007, Jeff King <peff@peff.net> wrote:
> > > This makes the fetch output much more terse. It is likely to
> > > be very controversial. Here's an example of the new output:
> > >
> > > Indexing objects: 100% (1061/1061), done.
> > > Resolving deltas: 100% (638/638), done.
> >
> > Those two lines are actually my beef with the fetch output. As a newbie, I had
> > no idea what "Indexing objects" actually meant. We have this thing called "the
> > index" in git so I would expect "Indexing objects" to have something to do
> > with that, but it doesn't seem to.
> >
> > How about something more descriptive of the high-level operation that's going
> > on, along the lines of:
> >
> > Gathering changes from remote: 100% (1061/1061), done.
> > Applying changes locally: 100% (638/638), done.
>
> This is even more wrong.
>
> Agreed, indexing objects might not be the best description. It probably
> will become "receiving objects" along with a bandwitth meter.
The term 'objects' here always confuses me. What is often my first
thing to check the number of individual commits being added after
a git pull. Wether a commit touches one or several files is less
important (to my way of using git).
Sam
^ permalink raw reply
* Re: [PATCH] allow git to use the PATH for finding subcommands and help docs
From: Johannes Schindelin @ 2007-10-19 17:19 UTC (permalink / raw)
To: Mike Hommey; +Cc: Scott Parish, Johannes Sixt, git
In-Reply-To: <20071019164816.GA24573@glandium.org>
Hi,
On Fri, 19 Oct 2007, Mike Hommey wrote:
> On Fri, Oct 19, 2007 at 04:27:39PM +0200, Johannes Schindelin wrote:
> > While reading this, I have to wonder why it is not just simpler to try
> > with builtin_exec_path first, and if that fails, just let exec() find the
> > program in the PATH?
>
> Why not try the directory where the git executable is, too ?
I commented on that. If the git command was not specified with an
absolute path, then make it absolute (and only if not even a relative path
was specified, ignore this altogether since git is in the PATH).
I was a bit terse on the issue I have to admit, though.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] allow git to use the PATH for finding subcommands and help docs
From: Mike Hommey @ 2007-10-19 16:48 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Scott Parish, Johannes Sixt, git
In-Reply-To: <Pine.LNX.4.64.0710191616490.16728@wbgn129.biozentrum.uni-wuerzburg.de>
On Fri, Oct 19, 2007 at 04:27:39PM +0200, Johannes Schindelin wrote:
> While reading this, I have to wonder why it is not just simpler to try
> with builtin_exec_path first, and if that fails, just let exec() find the
> program in the PATH?
Why not try the directory where the git executable is, too ?
Mike
^ permalink raw reply
* Re: [PATCH] allow git to use the PATH for finding subcommands and help docs
From: Johannes Sixt @ 2007-10-19 14:34 UTC (permalink / raw)
To: Scott Parish; +Cc: git
In-Reply-To: <20071019141805.GE1463@srparish.net>
Scott Parish schrieb:
> On Fri, Oct 19, 2007 at 03:21:12PM +0200, Johannes Sixt wrote:
>
>> Scott Parish schrieb:
>>> I have a situation where software for a distribution is installed
>>> into a fake "prefix" and then moved to one of several potential
>>> places to be used by users. Given that the final location isn't
>>> static, i can't depend on builtin_exec_path. I'd really like users
>>> to be able to get started with git as easily as possible. With the
>>> current setup, they would have to create and maintain either an
>>> GIT_EXEC_PATH or an alias for including --exec-path, as well as a
>>> MANPATH and PERL5LIB. This seem like an unnessisary burden.
>> Interesting. How does this compare to this 2-patch-series:
>>
>> http://repo.or.cz/w/git/mingw.git?a=commitdiff;h=e479ea2f911b8c70a269ba59372a4fef90f8907c
>> http://repo.or.cz/w/git/mingw.git?a=commitdiff;h=00a4ff4f3f8ec7e6b3ac15456f00b22b03f438ae
>>
>> which I had come up with to accomplish something very similar
>> (on Windows). Your approach looks superior, but I hadn't gone
>> into depths, yet.
>
> I know very little about what's available on windows. Looking at
> your code, it looks like the command isn't passed in in argv[0] and
> that it contains the windows style path seperators. My code currently
> assumes that PATH is a colon separated list, and that directories
> are separated with '/'. How should these assumptions change for
> windows?
The question is rather whether my patches would be sufficient to also
achieve your requirements. They turn bultin_exec_path into a non-constant
that derives exec-path from argv[0] (which on Windows happens to be
available in the global _pgmptr). Isn't this enough, or at least the essence
of what you need?
(How to get to the value of _pgmptr, ie. argv[0], on non-Windows is a
secondary matter.)
-- Hannes
^ permalink raw reply
* Re: [RFC/PATCH] git-fetch: mega-terse fetch output
From: Nicolas Pitre @ 2007-10-19 16:12 UTC (permalink / raw)
To: Steven Grimm; +Cc: Shawn O. Pearce, David Symonds, Jeff King, git
In-Reply-To: <4718D25A.7040109@midwinter.com>
On Fri, 19 Oct 2007, Steven Grimm wrote:
> On 19/10/2007, Jeff King <peff@peff.net> wrote:
> > This makes the fetch output much more terse. It is likely to
> > be very controversial. Here's an example of the new output:
> >
> > Indexing objects: 100% (1061/1061), done.
> > Resolving deltas: 100% (638/638), done.
>
> Those two lines are actually my beef with the fetch output. As a newbie, I had
> no idea what "Indexing objects" actually meant. We have this thing called "the
> index" in git so I would expect "Indexing objects" to have something to do
> with that, but it doesn't seem to.
>
> How about something more descriptive of the high-level operation that's going
> on, along the lines of:
>
> Gathering changes from remote: 100% (1061/1061), done.
> Applying changes locally: 100% (638/638), done.
This is even more wrong.
Agreed, indexing objects might not be the best description. It probably
will become "receiving objects" along with a bandwitth meter.
Nicolas
^ permalink raw reply
* Re: Proposed git mv behavioral change
From: Michael Witten @ 2007-10-19 15:57 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: git
In-Reply-To: <28B30BAE-9482-4219-924B-F0EDFB2936FB@wincent.com>
On 19 Oct 2007, at 7:33:39 AM, Wincent Colaiuta wrote:
>> 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?
>
> Here you're copying the content of A.txt as it was in the last
> (HEAD) commit, but from what the poster said he wants the content
> of A.txt as it is staged in the index (that is, there may be staged
> but uncomitted changes).
>
>> Better:
>>
>>> mv A.txt path/B.txt
>>> Point the index entry for A.txt to path/B.txt
>
> Yes, that is basically what he was asking for, as I read it.
You're right.
There is the subtlety in the first case that he's already staged
something.
^ permalink raw reply
* Re: [RFC/PATCH] git-fetch: mega-terse fetch output
From: Steven Grimm @ 2007-10-19 15:53 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: David Symonds, Jeff King, git
In-Reply-To: <4718D25A.7040109@midwinter.com>
(Sorry for the repeat; my mail client tried to send this as HTML at
first and the git list rejected it.)
On 19/10/2007, Jeff King <peff@peff.net> wrote:
> This makes the fetch output much more terse. It is likely to
> be very controversial. Here's an example of the new output:
>
> Indexing objects: 100% (1061/1061), done.
> Resolving deltas: 100% (638/638), done.
Those two lines are actually my beef with the fetch output. As a newbie,
I had no idea what "Indexing objects" actually meant. We have this thing
called "the index" in git so I would expect "Indexing objects" to have
something to do with that, but it doesn't seem to.
How about something more descriptive of the high-level operation that's
going on, along the lines of:
Gathering changes from remote: 100% (1061/1061), done.
Applying changes locally: 100% (638/638), done.
-Steve
^ permalink raw reply
* Re: [RFC/PATCH] git-fetch: mega-terse fetch output
From: Steven Grimm @ 2007-10-19 15:50 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: David Symonds, Jeff King, git
In-Reply-To: <20071019073938.GN14735@spearce.org>
On 19/10/2007, Jeff King <peff@peff.net> wrote:
> This makes the fetch output much more terse. It is likely to
> be very controversial. Here's an example of the new output:
>
> Indexing objects: 100% (1061/1061), done.
> Resolving deltas: 100% (638/638), done.
Those two lines are actually my beef with the fetch output. As a newbie,
I had no idea what "Indexing objects" actually meant. We have this thing
called "the index" in git so I would expect "Indexing objects" to have
something to do with that, but it doesn't seem to.
How about something more descriptive of the high-level operation that's
going on, along the lines of:
Gathering changes from remote: 100% (1061/1061), done.
Applying changes locally: 100% (638/638), done.
-Steve
^ permalink raw reply
* Re: [RFC/PATCH] git-fetch: mega-terse fetch output
From: Nicolas Pitre @ 2007-10-19 15:03 UTC (permalink / raw)
To: Karl Hasselström
Cc: Theodore Tso, Santi Béjar, Shawn O. Pearce, David Symonds,
Jeff King, git
In-Reply-To: <20071019143844.GB23765@diana.vm.bytemark.co.uk>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1393 bytes --]
On Fri, 19 Oct 2007, Karl Hasselström wrote:
> On 2007-10-19 07:38:22 -0400, Theodore Tso wrote:
>
> > Finally, one last question --- am I the only one who had to take a
> > second look at the whether the arrow should be <- or ->? The
> > question is whether we are saying "gitk is moving to include all of
> > spearce/gitk"; but I could also see it stated that we are assigning
> > refs/heads/gitk with refs/remotes/spearce/gitk, in which case the
> > arrow should be reversed. Or maybe:
> >
> > ==> git://repo.or.cz/git/spearce.git
> > * branch gitk := spearce/gitk (new)
> > * branch maint := spearce/maint 1aa3d01..e7187e4
> > * branch master := spearce/master de61e42..7840ce6
> > * branch next := spearce/next 895be02..2fe5433
> > + branch pu := spearce/pu 89fa332...1e4c517
> > * branch todo := spearce/todo (new)
>
> I think the reasoning behind the "foo -> spearce/foo" syntax is that
> "(refs/heads/)foo" in the remote repository has been fetched to
> "(refs/remotes/)spearce/foo" in the local repository.
Well, the important thing is that the _content_ is moving from the
remote repository to the local one. That's how the arrow should be
interpreted conceptually. The fact that technically we end up assigning
the local ref with the remote value is a technical issue.
Nicolas
^ permalink raw reply
* Re: [RFC/PATCH] git-fetch: mega-terse fetch output
From: Nicolas Pitre @ 2007-10-19 14:56 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Santi Béjar, Johannes Sixt, Theodore Tso, Shawn O. Pearce,
David Symonds, Jeff King, git
In-Reply-To: <Pine.LNX.4.64.0710191640250.16728@wbgn129.biozentrum.uni-wuerzburg.de>
On Fri, 19 Oct 2007, Johannes Schindelin wrote:
> Better to say (forced) if need be. But I do not think so. I like Hannes'
> proposal as-is.
I'm of that opinion too. Except maybe using a space instead of * for
fast forward, so the other types stand out more.
Nicolas
^ permalink raw reply
* Re: [RFC/PATCH] git-fetch: mega-terse fetch output
From: Nicolas Pitre @ 2007-10-19 14:54 UTC (permalink / raw)
To: Johannes Sixt
Cc: Santi Béjar, Theodore Tso, Shawn O. Pearce, David Symonds,
Jeff King, git
In-Reply-To: <4718C1DE.5030708@viscovery.net>
On Fri, 19 Oct 2007, Johannes Sixt wrote:
> The '*' could go away, then the '+' is more visible.
Agreed. ' ' = fast forward, '+' = forced update, and '!' = refused.
Nicolas
^ permalink raw reply
* Re: [RFC/PATCH] git-fetch: mega-terse fetch output
From: Nicolas Pitre @ 2007-10-19 14:52 UTC (permalink / raw)
To: Santi Béjar
Cc: Johannes Sixt, Theodore Tso, Shawn O. Pearce, David Symonds,
Jeff King, git
In-Reply-To: <8aa486160710190731v67626fd8wa94ba069a17f73ce@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 900 bytes --]
On Fri, 19 Oct 2007, Santi Béjar wrote:
> I like it too. I would like to add some more descripton, because I
> think for newbies the .. and ... can be overlooked. Something like:
>
> $ git fetch spearce
> ...
> URL: git://repo.or.cz/git/spearce.git
> * (new) spearce/gitk: new branch 'gitk'
> * 1aa3d01..e7187e4 spearce/maint: fast forward to branch 'maint'
> * de61e42..7840ce6 spearce/master: fast forward to branch 'master'
> * 895be02..2fe5433 spearce/next: fast forward to branch 'next'
> + 89fa332...1e4c517 spearce/pu: forcing update to non-fast forward branch 'pu'
> * (new) spearce/todo: new branch spearce/todo
Well, I don't like it as much. First I don't think newbies will care
much more even if the type of update is spelled out verbosely. Better
keep it short and add all the necessary information in the fetch man
page instead.
Nicolas
^ permalink raw reply
* Re: git push bug?
From: Joakim Tjernlund @ 2007-10-19 14:47 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Steffen Prohaska, git
In-Reply-To: <Pine.LNX.4.64.0710182259190.25221@racer.site>
On Thu, 2007-10-18 at 23:00 +0100, Johannes Schindelin wrote:
> Hi,
>
> On Thu, 18 Oct 2007, Joakim Tjernlund wrote:
>
> > On Thu, 2007-10-18 at 17:21 +0100, Johannes Schindelin wrote:
> >
> > > On Thu, 18 Oct 2007, Joakim Tjernlund wrote:
> > >
> > > > Seems like it is a bit too easy to make mistakes here. Why can I
> > > > delete a branch with :linus but not create one with linus:linus?
> > >
> > > I wonder why you bother with the colon at all. Just
> > >
> > > git push <remote> linus
> > >
> > > and be done with it. The colon is only there to play interesting
> > > games, not something as simple as "push this branch" or "push this
> > > tag".
> >
> > First, I didn't know that I could do that. Secondly, I was also looking
> > do v2.6.23:linus refspecs
>
>
> First, then our documentation could be better. How?
Well, it isn't clear to me how all this is supposed to work and
what is bugs. Clearifying that would help.
For instances I did a push with v2.6.23:refs/heads/linus and now
I got a branch with the SHA1 of v2.6.23 tag(0b8bc8b91cf6befea20fe78b90367ca7b61cfa0d)
in it. Makes gitk display that branch as "linus^{}".
>
> Second, why not "git checkout -b linus v2.6.23 && git push origin linus"?
An extra checkout that takes time but works. Doesn't make the above
"weiredness" go away though.
Jocke
>
> Ciao,
> Dscho
>
>
^ permalink raw reply
* Re: [RFC/PATCH] git-fetch: mega-terse fetch output
From: Johannes Schindelin @ 2007-10-19 14:41 UTC (permalink / raw)
To: Santi Béjar
Cc: Nicolas Pitre, Johannes Sixt, Theodore Tso, Shawn O. Pearce,
David Symonds, Jeff King, git
In-Reply-To: <8aa486160710190731v67626fd8wa94ba069a17f73ce@mail.gmail.com>
Hi,
On Fri, 19 Oct 2007, Santi B?jar wrote:
> On 10/19/07, Nicolas Pitre <nico@cam.org> wrote:
> > On Fri, 19 Oct 2007, Johannes Sixt wrote:
> >
> > > Theodore Tso schrieb:
> > > > ==> git://repo.or.cz/git/spearce.git
> > > > * branch gitk -> spearce/gitk (new)
> > > > * branch maint -> spearce/maint 1aa3d01..e7187e4
> > > > * branch master -> spearce/master de61e42..7840ce6
> > > > * branch next -> spearce/next 895be02..2fe5433
> > > > + branch pu -> spearce/pu 89fa332...1e4c517
> > > > * branch todo -> spearce/todo (new)
> > >
> > > > As far as the padding, it would be a pain to figure out how to make
> > > > the right hand column be padded so that it starts 3 spaces after the
> > > > longest " * branch foo -> bar" line, but that would look the best.
> > >
> > > But this way it wouldn't be difficult at all:
> > >
> > > ==> git://repo.or.cz/git/spearce.git
> > > * (new) gitk -> spearce/gitk
> > > * 1aa3d01..e7187e4 maint -> spearce/maint
> > > * de61e42..7840ce6 master -> spearce/master
> > > * 895be02..2fe5433 next -> spearce/next
> > > + 89fa332...1e4c517 pu -> spearce/pu
> > > * (new) todo -> spearce/todo
> >
> > Actually I think this is the best format so far: one line per branch, no
> > terminal width issue (long branch names are simply wrapped), the
> > old..new info is there also with the single character marker to quickly
> > notice the type of update.
>
> I like it too. I would like to add some more descripton, because I
> think for newbies the .. and ... can be overlooked. Something like:
>
> $ git fetch spearce
> ...
> URL: git://repo.or.cz/git/spearce.git
> * (new) spearce/gitk: new branch 'gitk'
Nah, that is just duplication.
> * 1aa3d01..e7187e4 spearce/maint: fast forward to branch 'maint'
> * de61e42..7840ce6 spearce/master: fast forward to branch 'master'
> * 895be02..2fe5433 spearce/next: fast forward to branch 'next'
> + 89fa332...1e4c517 spearce/pu: forcing update to non-fast forward branch 'pu'
Better to say (forced) if need be. But I do not think so. I like Hannes'
proposal as-is.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC/PATCH] git-fetch: mega-terse fetch output
From: Karl Hasselström @ 2007-10-19 14:40 UTC (permalink / raw)
To: Santi Béjar
Cc: Nicolas Pitre, Johannes Sixt, Theodore Tso, Shawn O. Pearce,
David Symonds, Jeff King, git
In-Reply-To: <8aa486160710190731v67626fd8wa94ba069a17f73ce@mail.gmail.com>
On 2007-10-19 16:31:08 +0200, Santi Béjar wrote:
> I would also put 'URL:' instead '==>'.
Seconded.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [RFC/PATCH] git-fetch: mega-terse fetch output
From: Johannes Sixt @ 2007-10-19 14:40 UTC (permalink / raw)
To: Santi Béjar
Cc: Nicolas Pitre, Theodore Tso, Shawn O. Pearce, David Symonds,
Jeff King, git
In-Reply-To: <8aa486160710190731v67626fd8wa94ba069a17f73ce@mail.gmail.com>
Santi Béjar schrieb:
> On 10/19/07, Nicolas Pitre <nico@cam.org> wrote:
>> On Fri, 19 Oct 2007, Johannes Sixt wrote:
>>> ==> git://repo.or.cz/git/spearce.git
>>> * (new) gitk -> spearce/gitk
>>> * 1aa3d01..e7187e4 maint -> spearce/maint
>>> * de61e42..7840ce6 master -> spearce/master
>>> * 895be02..2fe5433 next -> spearce/next
>>> + 89fa332...1e4c517 pu -> spearce/pu
>>> * (new) todo -> spearce/todo
>
> I like it too. I would like to add some more descripton, because I
> think for newbies the .. and ... can be overlooked.
The '*' could go away, then the '+' is more visible.
-- Hanes
^ permalink raw reply
* Re: [RFC/PATCH] git-fetch: mega-terse fetch output
From: Karl Hasselström @ 2007-10-19 14:38 UTC (permalink / raw)
To: Theodore Tso
Cc: Santi Béjar, Shawn O. Pearce, David Symonds, Jeff King, git
In-Reply-To: <20071019113822.GB16726@thunk.org>
On 2007-10-19 07:38:22 -0400, Theodore Tso wrote:
> Finally, one last question --- am I the only one who had to take a
> second look at the whether the arrow should be <- or ->? The
> question is whether we are saying "gitk is moving to include all of
> spearce/gitk"; but I could also see it stated that we are assigning
> refs/heads/gitk with refs/remotes/spearce/gitk, in which case the
> arrow should be reversed. Or maybe:
>
> ==> git://repo.or.cz/git/spearce.git
> * branch gitk := spearce/gitk (new)
> * branch maint := spearce/maint 1aa3d01..e7187e4
> * branch master := spearce/master de61e42..7840ce6
> * branch next := spearce/next 895be02..2fe5433
> + branch pu := spearce/pu 89fa332...1e4c517
> * branch todo := spearce/todo (new)
I think the reasoning behind the "foo -> spearce/foo" syntax is that
"(refs/heads/)foo" in the remote repository has been fetched to
"(refs/remotes/)spearce/foo" in the local repository.
I might be deluded, though.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ 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