* Re: several quick questions
From: Carl Worth @ 2006-02-14 20:14 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Nicolas Vilz 'niv', git
In-Reply-To: <Pine.LNX.4.64.0602141056170.3691@g5.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 586 bytes --]
On Tue, 14 Feb 2006 11:00:44 -0800 (PST), Linus Torvalds wrote:
> > And I think that would make for a dandy command to have in git. Any
> > suggestions for a name?
>
> I'd suggest "git reset" as a cool way to say that it "resets" the tree to
> another version ;)
Heh. It also moves a branch name though, and that's the part I don't
want. See my suggestion elsewhere of "git seek". [*]
-Carl
[*] Yes, I appear doomed to be reinventing cogito piecemeal. I got
"seek" from the error message in git-bisect, before I heard about
cg-seek, (as Junio pointed out elsewhere in the thread).
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: several quick questions
From: Petr Baudis @ 2006-02-14 20:27 UTC (permalink / raw)
To: Carl Worth; +Cc: Linus Torvalds, Nicolas Vilz 'niv', git
In-Reply-To: <87fymlvgzv.wl%cworth@cworth.org>
Dear diary, on Tue, Feb 14, 2006 at 09:10:28PM CET, I got a letter
where Carl Worth <cworth@cworth.org> said that...
> That gives a very natural name, "seek", for the operation I'd like.
>
> How about "git seek" for doing the operations above, and using some
> reserved branch name, (say "seek"). Then, git-bisect could easily be
> built on that, and git-commit could respect the "seek" name and refuse
> to commit to it, (could tell the user how to create the branch
> necessary to commit from the current point).
>
> There could also be a "git seek reset" to return to the HEAD saved by
> the first in a chain of "git seek" operations.
>
> That looks like I minor generalization of existing behavior in
> git-bisect, but it would provide an operation that I would find
> useful.
Well, this is exactly what cg-seek does (and it's one of pretty old
Cogito commands) - it even has the same name. ;-) See my other mail in
this thread.
It works by creating a new branch cg-seek-point and storing the seeked
point there; if HEAD is already on the branch, it merely changes the
seek point and resets the working tree appropriately. cg-seek without
any arguments will then return to your original head, whose name was
stored in .git/head-name.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Re: several quick questions
From: Johannes Schindelin @ 2006-02-14 20:34 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <43F231C5.5010205@op5.se>
Hi,
On Tue, 14 Feb 2006, Andreas Ericsson wrote:
> [...] it would be nifty (and I imagine not particularly hard) to teach
> "git checkout" to check out any revision, and not just a branch.
You have to have a valid HEAD. So, you can create a throw-away branch
easily:
git-checkout -f throw HEAD~56
Hth,
Dscho
^ permalink raw reply
* Re: several quick questions
From: Johannes Schindelin @ 2006-02-14 20:37 UTC (permalink / raw)
To: Petr Baudis; +Cc: Carl Worth, git
In-Reply-To: <20060214202728.GE31278@pasky.or.cz>
Hi,
On Tue, 14 Feb 2006, Petr Baudis wrote:
> [...]
>
> It works by creating a new branch cg-seek-point and storing the seeked
> point there; if HEAD is already on the branch, it merely changes the
> seek point and resets the working tree appropriately. cg-seek without
> any arguments will then return to your original head, whose name was
> stored in .git/head-name.
And if you want to prevent accidental commit, just "chmod a-w
$GIT_DIR/index".
Ciao,
Dscho
^ permalink raw reply
* Re: several quick questions
From: Linus Torvalds @ 2006-02-14 20:40 UTC (permalink / raw)
To: Carl Worth; +Cc: Nicolas Vilz 'niv', git
In-Reply-To: <87fymlvgzv.wl%cworth@cworth.org>
On Tue, 14 Feb 2006, Carl Worth wrote:
> >
> > What a strange thing to ask for.
>
> It's pretty common in other tools.
Well, it's pretty common in git too. But in git, the notion of "branch"
really has been made so cheap that it's basically a no-op.
The "overhead" of creating a branch is literally the cost of writing one
(small) file.
> In fact, this is the natural operation for the basis of something like
> git-bisect.
Right. And "git bisect" very much does exactly that. It creates a
temporary branch for bisection (the branch is called "bisect", one of the
less confusing naming decisions in git ;)
That's really my point. It all boils down to the same three operations:
"git branch", "git checkout" and "git reset".
In fact, if you look into git-bisect, you'll notice that it doesn't even
use "git reset" internally. It _literally_ creates a new branch (which it
does by hand for some strange reason, but never mind) called "new-bisect",
and then does "git checkout new-bisect" followed by renaming the branch
back to "bisect" (which it again does by hand).
So "git bisect" may actually get its hands dirty by knowing a bit too much
about the internal workings of git branches, but conceptually, it really
does just
git checkout -b new-bisect <newrev>
to switch its state around.
> But I'd still like to be able to do this without having to invent a
> fake branch name, without the ability to accidentally commit on the
> fake branch, and without the possibility of accidentally leaving those
> commits dangling the next time I seek somewhere else.
Pasky did this before the "multi-branch" thing was common, and calls it
"cg-seek".
I think that does exactly what you ask for, I just don't really see the
point. The downside of cg-seek is that you're really really limited to
what you can do with it.
For example, it may be "overhead" to have a dummy branch for bisection,
but it means (for example) that you can actually do real work on the point
that "git bisect" points you to.
For example, if you hit a compile error, you can _literally_ fix that
compile error AND COMMIT that state, and when you then mark that commit
"good" or "bad" when you continue to bisect, bisection will actually do
the right thing. Something that would be impossible in a "seek"
environment, where you don't have a branch that you can do development on.
I realize that when you come from an environment where branches are big
things, this is kind of strange. But in git, a branch is literally a
single file that is 41 bytes in size. That's it. No more, no less.
Linus
^ permalink raw reply
* Re: several quick questions
From: Junio C Hamano @ 2006-02-14 20:41 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0602142136250.23659@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Tue, 14 Feb 2006, Petr Baudis wrote:
>
>> [...]
>>
>> It works by creating a new branch cg-seek-point and storing the seeked
>> point there; if HEAD is already on the branch, it merely changes the
>> seek point and resets the working tree appropriately. cg-seek without
>> any arguments will then return to your original head, whose name was
>> stored in .git/head-name.
>
> And if you want to prevent accidental commit, just "chmod a-w
> $GIT_DIR/index".
That is a wrong answer. It is perfectly sane to modify index
without an intention to commit that change (you can always say
"git reset").
^ permalink raw reply
* [PATCH] commit: detect misspelled pathspec while making a partial commit.
From: Junio C Hamano @ 2006-02-14 20:46 UTC (permalink / raw)
To: pasky; +Cc: git
When you say "git commit Documentaiton" to make partial commit
for the files only in that directory, we did not detect that as
a misspelled pathname and attempted to commit index without
change. If nothing matched, there is no harm done, but if the
index gets modified otherwise by having another valid pathspec
or after an explicit update-index, a user will not notice
without paying attention to the "git status" preview.
This introduces --error-unmatch option to ls-files, and uses it
to detect this common user error.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* Pasky, does this address the issue you mentioned earlier on
the #git channnel?
git-commit.sh | 16 +++++++++-------
ls-files.c | 51 ++++++++++++++++++++++++++++++++++++++++++++-------
2 files changed, 53 insertions(+), 14 deletions(-)
c49ee6e0bba6c800f2c36df819973f3caac20fa4
diff --git a/git-commit.sh b/git-commit.sh
index ab5e6bc..f7ee1aa 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -180,6 +180,7 @@ verify=t
verbose=
signoff=
force_author=
+only_include_assumed=
while case "$#" in 0) break;; esac
do
case "$1" in
@@ -340,12 +341,8 @@ case "$#,$also$only" in
0,)
;;
*,)
- echo >&2 "assuming --only paths..."
+ only_include_assumed="# Explicit paths specified without -i nor -o; assuming --only paths..."
also=
-
- # If we are going to launch an editor, the message won't be
- # shown without this...
- test -z "$log_given$status_only" && sleep 1
;;
esac
unset only
@@ -380,6 +377,8 @@ t,)
;;
,t)
save_index &&
+ git-ls-files --error-unmatch -- "$@" >/dev/null || exit
+
git-diff-files --name-only -z -- "$@" |
(
cd "$TOP"
@@ -408,7 +407,7 @@ t,)
refuse_partial "Different in index and the last commit:
$dirty_in_index"
fi
- commit_only=`git-ls-files -- "$@"`
+ commit_only=`git-ls-files --error-unmatch -- "$@"` || exit
# Build the temporary index and update the real index
# the same way.
@@ -569,7 +568,10 @@ else
PARENTS=""
fi
-run_status >>"$GIT_DIR"/COMMIT_EDITMSG
+{
+ test -z "$only_include_assumed" || echo "$only_include_assumed"
+ run_status
+} >>"$GIT_DIR"/COMMIT_EDITMSG
if [ "$?" != "0" -a ! -f "$GIT_DIR/MERGE_HEAD" ]
then
rm -f "$GIT_DIR/COMMIT_EDITMSG"
diff --git a/ls-files.c b/ls-files.c
index 7024cf1..a716e5f 100644
--- a/ls-files.c
+++ b/ls-files.c
@@ -25,6 +25,8 @@ static int line_terminator = '\n';
static int prefix_len = 0, prefix_offset = 0;
static const char *prefix = NULL;
static const char **pathspec = NULL;
+static int error_unmatch = 0;
+static char *ps_matched = NULL;
static const char *tag_cached = "";
static const char *tag_unmerged = "";
@@ -325,7 +327,8 @@ static int cmp_name(const void *p1, cons
* Match a pathspec against a filename. The first "len" characters
* are the common prefix
*/
-static int match(const char **spec, const char *filename, int len)
+static int match(const char **spec, char *ps_matched,
+ const char *filename, int len)
{
const char *m;
@@ -333,17 +336,24 @@ static int match(const char **spec, cons
int matchlen = strlen(m + len);
if (!matchlen)
- return 1;
+ goto matched;
if (!strncmp(m + len, filename + len, matchlen)) {
if (m[len + matchlen - 1] == '/')
- return 1;
+ goto matched;
switch (filename[len + matchlen]) {
case '/': case '\0':
- return 1;
+ goto matched;
}
}
if (!fnmatch(m + len, filename + len, 0))
- return 1;
+ goto matched;
+ if (ps_matched)
+ ps_matched++;
+ continue;
+ matched:
+ if (ps_matched)
+ *ps_matched = 1;
+ return 1;
}
return 0;
}
@@ -356,7 +366,7 @@ static void show_dir_entry(const char *t
if (len >= ent->len)
die("git-ls-files: internal error - directory entry not superset of prefix");
- if (pathspec && !match(pathspec, ent->name, len))
+ if (pathspec && !match(pathspec, ps_matched, ent->name, len))
return;
fputs(tag, stdout);
@@ -444,7 +454,7 @@ static void show_ce_entry(const char *ta
if (len >= ce_namelen(ce))
die("git-ls-files: internal error - cache entry not superset of prefix");
- if (pathspec && !match(pathspec, ce->name, len))
+ if (pathspec && !match(pathspec, ps_matched, ce->name, len))
return;
if (!show_stage) {
@@ -699,6 +709,10 @@ int main(int argc, const char **argv)
prefix_offset = 0;
continue;
}
+ if (!strcmp(arg, "--error-unmatch")) {
+ error_unmatch = 1;
+ continue;
+ }
if (*arg == '-')
usage(ls_files_usage);
break;
@@ -710,6 +724,14 @@ int main(int argc, const char **argv)
if (pathspec)
verify_pathspec();
+ /* Treat unmatching pathspec elements as errors */
+ if (pathspec && error_unmatch) {
+ int num;
+ for (num = 0; pathspec[num]; num++)
+ ;
+ ps_matched = xcalloc(1, num);
+ }
+
if (show_ignored && !exc_given) {
fprintf(stderr, "%s: --ignored needs some exclude pattern\n",
argv[0]);
@@ -725,5 +747,20 @@ int main(int argc, const char **argv)
if (prefix)
prune_cache();
show_files();
+
+ if (ps_matched) {
+ /* We need to make sure all pathspec matched otherwise
+ * it is an error.
+ */
+ int num, errors = 0;
+ for (num = 0; pathspec[num]; num++) {
+ if (ps_matched[num])
+ continue;
+ error("pathspec '%s' did not match any.",
+ pathspec[num] + prefix_len);
+ }
+ return errors ? 1 : 0;
+ }
+
return 0;
}
--
1.2.0.g6552
^ permalink raw reply related
* Re: several quick questions
From: Johannes Schindelin @ 2006-02-14 20:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmzgtr7u2.fsf@assigned-by-dhcp.cox.net>
Hi,
On Tue, 14 Feb 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Hi,
> >
> > On Tue, 14 Feb 2006, Petr Baudis wrote:
> >
> >> [...]
> >>
> >> It works by creating a new branch cg-seek-point and storing the seeked
> >> point there; if HEAD is already on the branch, it merely changes the
> >> seek point and resets the working tree appropriately. cg-seek without
> >> any arguments will then return to your original head, whose name was
> >> stored in .git/head-name.
> >
> > And if you want to prevent accidental commit, just "chmod a-w
> > $GIT_DIR/index".
>
> That is a wrong answer. It is perfectly sane to modify index
> without an intention to commit that change (you can always say
> "git reset").
Okay, I was not being completely truthful. If I did not get the original
idea of git-seek wrong, then it was kind of an excursion, just taking a
peek. And if you want to return from that excursion, I thought maybe it
would make sense to disallow index operations *at all* until returning to
the HEAD.
But I agree it is nasty. And Linus mentioned that the benefits of being
able to commit into a temporary branch outweigh the shortcoming easily.
(The shortcoming being that you have to keep in mind that you are in
another branch. Which does not come easily to a fresh CVS convert.)
Ciao,
Dscho
^ permalink raw reply
* Re: several quick questions
From: Petr Baudis @ 2006-02-14 20:55 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Carl Worth, git
In-Reply-To: <Pine.LNX.4.63.0602142136250.23659@wbgn013.biozentrum.uni-wuerzburg.de>
Hi,
Dear diary, on Tue, Feb 14, 2006 at 09:37:39PM CET, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> On Tue, 14 Feb 2006, Petr Baudis wrote:
>
> > [...]
> >
> > It works by creating a new branch cg-seek-point and storing the seeked
> > point there; if HEAD is already on the branch, it merely changes the
> > seek point and resets the working tree appropriately. cg-seek without
> > any arguments will then return to your original head, whose name was
> > stored in .git/head-name.
>
> And if you want to prevent accidental commit, just "chmod a-w
> $GIT_DIR/index".
currently, Cogito has a generic "blocking" mechanism which will
prevent you to do operations mutating the history (mostly committing and
mergnign) - seeking is the only user now.
Note that this is not very flexible and I consider this legacy stuff;
I will replace that by a specific check for a seek when I have some time
(which will also make it compatible with the git-bisect-using-headname).
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Re: [ANNOUNCE] pg - A patch porcelain for GIT
From: Chuck Lever @ 2006-02-14 20:58 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Catalin Marinas, git
In-Reply-To: <20060214160747.GA6350@diana.vm.bytemark.co.uk>
[-- Attachment #1: Type: text/plain, Size: 1717 bytes --]
Karl Hasselström wrote:
> On 2006-02-14 10:22:51 -0500, Chuck Lever wrote:
>
>
>>Karl Hasselström wrote:
>>
>>
>>>One thing I would like to see in stgit is the opposite of "stg
>>>commit"; instead of converting patches to regular commits, take
>>>the topmost regular commits and convert them to patches.
>>>
>>>For example, "stg uncommit foo bar baz" would -- regardless of any
>>>existing patches, applied or not -- convert the top three regular
>>>commits, with comments and all, to stgit patches called foo, bar,
>>>and baz. These would be already applied, at the bottom of the
>>>stack. I imagine all one would have to do is to modify some stgit
>>>metadata, so the operation could be really cheap.
>>>
>>>Of course, "stg uncommit" is allowed to reject any commit with
>>>more than one parent, since those can't be represented as stgit
>>>patches.
>>>
>>>This would perhaps not add much power to an all-stgit workflow,
>>>but it would be a really convenient way to edit recent git
>>>history. Sort of like a more convenient rebase. And a great way to
>>>lure new users. :-)
>>
>>i think you want "stg pick --reverse" ?
>
>
> No, I literally want the opposite of "stg commit", so that the
> sequence "stg commit; stg uncommit" has zero net effect.
gotcha.
well, that would work OK for maintainers, but would be kind of strange
for folks who are pulling from such a repository. how would that work?
my impression of git is that you don't change stuff that's already
committed. you revert changes by applying a new commit that backs out
the original changes. i'm speculating, but i suspect that's why there's
a "stg pick --reverse" and not a "stg uncommit."
[-- Attachment #2: cel.vcf --]
[-- Type: text/x-vcard, Size: 451 bytes --]
begin:vcard
fn:Chuck Lever
n:Lever;Charles
org:Network Appliance, Incorporated;Open Source NFS Client Development
adr:535 West William Street, Suite 3100;;Center for Information Technology Integration;Ann Arbor;MI;48103-4943;USA
email;internet:cel@citi.umich.edu
title:Member of Technical Staff
tel;work:+1 734 763 4415
tel;fax:+1 734 763 4434
tel;home:+1 734 668 1089
x-mozilla-html:FALSE
url:http://troy.citi.umich.edu/u/cel/
version:2.1
end:vcard
^ permalink raw reply
* Re: several quick questions
From: Petr Baudis @ 2006-02-14 21:19 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Carl Worth, Nicolas Vilz 'niv', git
In-Reply-To: <Pine.LNX.4.64.0602141224110.3691@g5.osdl.org>
Dear diary, on Tue, Feb 14, 2006 at 09:40:24PM CET, I got a letter
where Linus Torvalds <torvalds@osdl.org> said that...
> On Tue, 14 Feb 2006, Carl Worth wrote:
> > But I'd still like to be able to do this without having to invent a
> > fake branch name, without the ability to accidentally commit on the
> > fake branch, and without the possibility of accidentally leaving those
> > commits dangling the next time I seek somewhere else.
>
> Pasky did this before the "multi-branch" thing was common, and calls it
> "cg-seek".
>
> I think that does exactly what you ask for, I just don't really see the
> point. The downside of cg-seek is that you're really really limited to
> what you can do with it.
>
> For example, it may be "overhead" to have a dummy branch for bisection,
> but it means (for example) that you can actually do real work on the point
> that "git bisect" points you to.
>
> For example, if you hit a compile error, you can _literally_ fix that
> compile error AND COMMIT that state, and when you then mark that commit
> "good" or "bad" when you continue to bisect, bisection will actually do
> the right thing. Something that would be impossible in a "seek"
> environment, where you don't have a branch that you can do development on.
That's a neat idea - I like this. I just tweaked cg-commit -f so that it
will now override the cg-seek block, with a warning that you should be
content about your commit being thrown away.
Really, except this blocking restriction (which is really a check for a
non-empty .git/blocked file), cg-seek does exactly the fake branch
thing, as you actually persuaded me to do. So you are on a dedicated
seeking branch and theoretically you can do development on it - it's
only too easy to lose the commits.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Re: Handling large files with GIT
From: Sam Vilain @ 2006-02-14 21:21 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Johannes Schindelin, Ian Molton, git
In-Reply-To: <Pine.LNX.4.64.0602141108050.3691@g5.osdl.org>
Linus Torvalds wrote:
> That said, I think git could do much better if the layout was optimized
> for git. For example, in the maildir thing, there's two issues: the flat
> directory structure is sub-optimal, but the other thing seems to be that
> maildir apparently saves metadata in the filename.
>
> Saving meta-data in the filename should actually work wonderfully well
> with git, but both merging and git-diff-tree consider the filename to be
> the "index", so they optimize for that. You could do indexing the other
> way around, and consider the contents to be the index (and the filename is
> the "status"), but that's obviously not sane for a sw project, even if it
> might be exactly what you want to do for mail handling.
This seems to me to be another use case where git could gain orders of
magnitude speed improvement by either explicit ("forensic") history
objects, or a history analysis cache.
Sam.
^ permalink raw reply
* Re: [PATCH] commit: detect misspelled pathspec while making a partial commit.
From: Petr Baudis @ 2006-02-14 21:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfymlr7n8.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Tue, Feb 14, 2006 at 09:46:03PM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> When you say "git commit Documentaiton" to make partial commit
> for the files only in that directory, we did not detect that as
> a misspelled pathname and attempted to commit index without
> change. If nothing matched, there is no harm done, but if the
> index gets modified otherwise by having another valid pathspec
> or after an explicit update-index, a user will not notice
> without paying attention to the "git status" preview.
>
> This introduces --error-unmatch option to ls-files, and uses it
> to detect this common user error.
>
> Signed-off-by: Junio C Hamano <junkio@cox.net>
>
> ---
>
> * Pasky, does this address the issue you mentioned earlier on
> the #git channnel?
Yes, this is what I meant. I actually have no practical experience with
this since I'm not a git-commit user, I merely expressed horror ;) on
what you mentioned during the night. BUT it turns out that this affects
Cogito as well, albeit in a milder version - only when you pass multiple
explicit paths to cg-commit and some of them are misspelled, they are
ignored quietly (unless all of them are misspelled).
So, thanks for the fix on behalf of Cogito users as well. ;-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Re: several quick questions
From: Josef Weidendorfer @ 2006-02-14 21:30 UTC (permalink / raw)
To: Carl Worth; +Cc: git, Linus Torvalds
In-Reply-To: <87fymlvgzv.wl%cworth@cworth.org>
On Tuesday 14 February 2006 21:10, you wrote:
> How about "git seek" for doing the operations above, and using some
> reserved branch name, (say "seek"). Then, git-bisect could easily be
> built on that, and git-commit could respect the "seek" name and refuse
> to commit to it, (could tell the user how to create the branch
> necessary to commit from the current point).
Why not allow something like
git-checkout master~5
which implicitly does create a read-only branch "seek-point"?
I do not think that it is important to remember the branch name you seek
from.
A branch could be marked readonly by above command with
chmod a-w .git/refs/heads/seek
And git-commit should refuse to commit on a readonly ref, telling
the user to create a writable branch before with "git-branch new".
This would also help "cg-seek" to prohibit the user to commit on
"cg-seek-point" via "git-commit" (by setting cg-seek-point read-only).
BTW, "origin" (and any local branch that tracks a remote one) should
be set to readonly this way to signal that these are not developer
branches.
Josef
^ permalink raw reply
* Re: several quick questions
From: Nicolas Vilz 'niv' @ 2006-02-14 21:30 UTC (permalink / raw)
To: git
In-Reply-To: <43F20D4B.3060606@op5.se>
Andreas Ericsson wrote:
>
> git will recognize the merge-base as being the current HEAD and simply
> sets HEAD to point to that of topic-branch. This is why it's called a
> fast-forward, since no heavy computing needs to be done to combine the
> two development tracks.
well finaly, if nothing happened in one of the lines, then the two lines
become the same, when merging back into one line. and the two lines
overlay each other. That is what i saw during playing with git-merge,
git-pull and git-reset.. ok.
>
>> do you have to make a new private branch out of the tag 1.1.6?
>>
>
> No, you don't, but you can if you wish. It's nifty if you want to fork
> the development from a particular branch. In your case, if you really,
> really *want* the arrows pointing to one line, you can do
>
> $ git branch topic-branch HEAD^
> # work, work, work
> $ git checkout master
> $ git pull . topic-branch
>
> That would create one pretty arrow. When multiple tracks of development
> (rather than just two) are combined into one it's called an octopus
> merge. Unless you really know what you're doing, you should try to avoid
> those for small projects, and doing it just for the pretty arrows is....
> well, let's call it "interesting from the behaviour science scholars
> point of view".
its just the thought "cool, it looks like there at the git repo"... just
to realize "ok, that happens, when i merge two trees.
>> i used svn and there i could go back some revisions. I haven't found
>> such a feature in git, yet... but i think i am blind all the time.
>>
>
> Most likely. I believe at least the reset command is mentioned in the
> tutorial. I trust you've read it before asking, so something is amiss
> either with your eyesight or the tutorial.
well the namespace of the references confused me, before i realized,
that HEAD finally points to an sha1sum (which symbolizes a certain commit)
mh.. I use pull if i want to get an external development tree, right? I
still search for a possibility to replace the svn:externals, which were
quite handy some times.
lets imagine, i want to reuse work i did in another repository, then I
can easily pull from that repository, which my work i want to reuse is
stored at... i see... i just will have to pull frequently.... and hope
there is no conflict between some files.
once more... thank you all and good work.
Nicolas
^ permalink raw reply
* Re: several quick questions
From: Junio C Hamano @ 2006-02-14 21:40 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
In-Reply-To: <200602142230.11442.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
> Why not allow something like
>
> git-checkout master~5
>
> which implicitly does create a read-only branch "seek-point"?
Now what does "git-checkout branch" mean? Does it switch to the
branch, or does it force tip of seek-point to be the tip of
branch and switch to seek-point branch? More interestingly,
what does "git-checkout seek-point" mean?
If we _were_ to do something like cg-seek where an implicit
throw-away branch is used, you at least need a way to
disambiguate these cases, and "git seek" originally suggested is
far clearer than what you said above.
Having said that, I am not convinced in either way, though.
> A branch could be marked readonly by above command with
>
> chmod a-w .git/refs/heads/seek
I do not think that would work. Have you tried it?
> And git-commit should refuse to commit on a readonly ref, telling
> the user to create a writable branch before with "git-branch new".
Now, read-only ref does not interest me, but "do not commit on
top of this yourself, only fast-forward from somewhere else is
allowed" may be useful, for the reason why you mentioned
"origin".
^ permalink raw reply
* Re: several quick questions
From: Petr Baudis @ 2006-02-14 21:41 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: Carl Worth, git, Linus Torvalds
In-Reply-To: <200602142230.11442.Josef.Weidendorfer@gmx.de>
Dear diary, on Tue, Feb 14, 2006 at 10:30:11PM CET, I got a letter
where Josef Weidendorfer <Josef.Weidendorfer@gmx.de> said that...
> Why not allow something like
>
> git-checkout master~5
>
> which implicitly does create a read-only branch "seek-point"?
> I do not think that it is important to remember the branch name you seek
> from.
>
> A branch could be marked readonly by above command with
>
> chmod a-w .git/refs/heads/seek
>
> And git-commit should refuse to commit on a readonly ref, telling
> the user to create a writable branch before with "git-branch new".
We just abolished symlinks. Can we afford doing this, from the
portability standpoint?
> This would also help "cg-seek" to prohibit the user to commit on
> "cg-seek-point" via "git-commit" (by setting cg-seek-point read-only).
For now, this is accomplished (in Cogito, but we just introduced this to
git-bisect as well) by creating .git/head-name. This has the advantage
that you know to which branch to return after the seeking is over, and
it also marks the current head "read-only" (in the commit sense) for
Cogito (and git-bisect start).
It is obviously less flexible since it lets you mark only the current
head read-only, but noone asked for more before. ;)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Re: several quick questions
From: Carl Worth @ 2006-02-14 21:53 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Nicolas Vilz 'niv', git
In-Reply-To: <Pine.LNX.4.64.0602141224110.3691@g5.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 1802 bytes --]
On Tue, 14 Feb 2006 12:40:24 -0800 (PST), Linus Torvalds wrote:
>
> That's really my point. It all boils down to the same three operations:
> "git branch", "git checkout" and "git reset".
Yes. I understand that much.
> I think that does exactly what you ask for, I just don't really see the
> point. The downside of cg-seek is that you're really really limited to
> what you can do with it.
Well, I think it would be useful to generalize and export what
git-bisect currently does even if there are no limitations added to
it. If nothing else, it's a tiny bit of sugar to allow exploring the
tree without having to invent a branch name first.
So I'd be happy with "git seek" even if git-commit didn't refuse to
commit on the seek branch, (but I still think that limitation makes
sense---see below).
> For example, if you hit a compile error, you can _literally_ fix that
> compile error AND COMMIT that state, and when you then mark that commit
> "good" or "bad" when you continue to bisect, bisection will actually do
> the right thing. Something that would be impossible in a "seek"
> environment, where you don't have a branch that you can do
> development on.
The only difference in the "seek" case would be that you would be
required to create a branch before committing, right?
And this would have the benefit of not leaving the commit object
dangling after continuing the bisect, wouldn't it?
You've pointed out that branches are free in terms of what git has to
do. I'm saying that they're not free for the user who bears the cost
of inventing a name. And in the case of any commit-while-seeking, it's
at the time of the commit itself that the user has enough information
to invent a useful name, not prior to seeking, (when the user is still
trying to figure things out).
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Handling large files with GIT
From: Linus Torvalds @ 2006-02-14 22:01 UTC (permalink / raw)
To: Sam Vilain; +Cc: Johannes Schindelin, Ian Molton, git
In-Reply-To: <43F249F7.5060008@vilain.net>
On Wed, 15 Feb 2006, Sam Vilain wrote:
>
> This seems to me to be another use case where git could gain orders of
> magnitude speed improvement by either explicit ("forensic") history
> objects, or a history analysis cache.
Well, the thing is, it could get that _without_ any cache too.
The problem really isn't that we couldn't make things faster, the problem
is that at least for _me_ the thing is fast enough.
If somebody is interested in making the "lots of filename changes" case go
fast, I'd be more than happy to walk them through what they'd need to
change. I'm just not horribly motivated to do it myself. Hint, hint.
Linus
^ permalink raw reply
* Re: several quick questions
From: Josef Weidendorfer @ 2006-02-14 22:17 UTC (permalink / raw)
To: git
In-Reply-To: <7v7j7xr54u.fsf@assigned-by-dhcp.cox.net>
On Tuesday 14 February 2006 22:40, you wrote:
> Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
>
> > Why not allow something like
> >
> > git-checkout master~5
> >
> > which implicitly does create a read-only branch "seek-point"?
>
> Now what does "git-checkout branch" mean? Does it switch to the
> branch, or does it force tip of seek-point to be the tip of
> branch and switch to seek-point branch? More interestingly,
> what does "git-checkout seek-point" mean?
You are right; it would get quite confusing.
But perhaps the current error message
git checkout: you need to specify a new branch name
should be a little bit more explaining by appending
"... to switch to for being able to checkout the requested revision"
> Having said that, I am not convinced in either way, though.
Me too. Specifying a branch name is easy enough.
> > And git-commit should refuse to commit on a readonly ref, telling
> > the user to create a writable branch before with "git-branch new".
>
> Now, read-only ref does not interest me, but "do not commit on
> top of this yourself, only fast-forward from somewhere else is
> allowed" may be useful, for the reason why you mentioned
> "origin".
Yes. The idea to make the ref readonly to specify this intent was
a quick (not so good) idea.
Still, being able to specify that you can not commit on some branch
(as you said) is very useful to prohibit doing things by accident.
.git/config does not sound very good for such a thing, especially
if there could be other branch-specific properties in the future.
Josef
^ permalink raw reply
* Re: several quick questions
From: Junio C Hamano @ 2006-02-14 22:26 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
In-Reply-To: <200602142317.29626.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
> On Tuesday 14 February 2006 22:40, you wrote:
>> Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
>>
>> > Why not allow something like
>> >
>> > git-checkout master~5
>> >
>> > which implicitly does create a read-only branch "seek-point"?
>>
>> Now what does "git-checkout branch" mean? Does it switch to the
>> branch, or does it force tip of seek-point to be the tip of
>> branch and switch to seek-point branch? More interestingly,
>> what does "git-checkout seek-point" mean?
>
> You are right; it would get quite confusing.
> But perhaps the current error message
>
> git checkout: you need to specify a new branch name
>
> should be a little bit more explaining by appending
>
> "... to switch to for being able to checkout the requested revision"
While we are on the subject of improving the error message to
better guide users in a likely-to-be-what-he-meant direction,
there is another confusing message (I am assuming you are
interested in this enough to come up with a patch to fix that
"... to switch to ..." thing):
$ git checkout -b test v2.6.10
The user wanted to create a new branch test based on tag
v2.6.10, alas that tag does not exist. We give quite confusing
error message because we are confused that the user meant to
checkout only "./v2.6.10" file and that operation and switching
branches are incompatible.
^ permalink raw reply
* Re: [ANNOUNCE] pg - A patch porcelain for GIT
From: Petr Baudis @ 2006-02-14 22:29 UTC (permalink / raw)
To: Chuck Lever; +Cc: Karl Hasselström, Catalin Marinas, git
In-Reply-To: <43F2445A.6020109@citi.umich.edu>
Dear diary, on Tue, Feb 14, 2006 at 09:58:02PM CET, I got a letter
where Chuck Lever <cel@citi.umich.edu> said that...
> my impression of git is that you don't change stuff that's already
> committed. you revert changes by applying a new commit that backs out
> the original changes. i'm speculating, but i suspect that's why there's
> a "stg pick --reverse" and not a "stg uncommit."
It is ok as long as you know what are you doing - if you don't push out
the commits you've just "undid" (or work on a public accessible
repository in the first place, but I think that's kind of rare these
days; quick survey - does anyone reading these lines do that?), there's
nothing wrong on it, and it gives you nice flexibility.
For example, to import bunch of patches (I guess that's the original
intention behind this) you just run git-am on them and then stg uncommit
all of the newly added commits.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Re: diffstat wierdness with 'git format-patch' output
From: Fredrik Kuivinen @ 2006-02-14 22:30 UTC (permalink / raw)
To: Greg KH; +Cc: git
In-Reply-To: <20060214055425.GA32261@kroah.com>
On Mon, Feb 13, 2006 at 09:54:25PM -0800, Greg KH wrote:
> I was trying to use the built-in git tools to send patches off, instead
> of my horribly hacked up scripts that use the git low-level stuff, when
> I noticed that git format-patch's output confuses diffstat a bit, and
> causes it to add another line to it's count.
>
> This isn't good when I do a 'diffstat -p1 *.txt' of the output and add
> it to an email to send off for someone to pull from, as the result will
> be off from what is really there.
>
> Here's what I get:
>
> $ git format-patch -n origin..HEAD
> 0001-USB-fix-up-the-usb-early-handoff-logic-for-EHCI.txt
> 0002-USB-add-new-device-ids-to-ldusb.txt
> 0003-USB-change-ldusb-s-experimental-state.txt
> 0004-USB-PL2303-Leadtek-9531-GPS-Mouse.txt
> 0005-USB-sl811_cs-needs-platform_device-conversion-too.txt
> 0006-usb-storage-new-unusual_devs-entry.txt
> 0007-usb-storage-unusual_devs-entry.txt
> 0008-USB-unusual_devs.h-entry-TrekStor-i.Beat.txt
> 0009-USB-unusual_devs.h-entry-iAUDIO-M5.txt
> 0010-USB-unusual-devs-bugfix.txt
>
> $ git log | head -n 1
> commit 16f05be7be0bf121491d83bd97337fe179b3b323
>
> $ git show 16f05be7be0bf121491d83bd97337fe179b3b323 | diffstat -p1
> drivers/usb/storage/unusual_devs.h | 25 ++++++++++++++++++-------
> 1 file changed, 18 insertions(+), 7 deletions(-)
>
> $ diffstat -p1 0010-USB-unusual-devs-bugfix.txt
> drivers/usb/storage/unusual_devs.h | 26 ++++++++++++++++++--------
> 1 file changed, 18 insertions(+), 8 deletions(-)
>
> Any thoughts?
>
If you don't have to generate the diffstat from the individual patches
then
git-diff-tree -p origin HEAD | git-apply --stat
should give you what you want.
BTW when I tried the above command on two random tags in the git tree
I got:
$ git-diff-tree -p v1.2.0 v1.0.8 | diffstat -p1 | tail -1
165 files changed, 3913 insertions(+), 8092 deletions(-)
and
$ git-diff-tree -p v1.2.0 v1.0.8 | git apply --stat | tail -1
160 files changed, 3925 insertions(+), 8092 deletions(-)
The difference seems to be caused by diffstat which seems to think
that all lines starting with '---' are diff headers. Hence, there are
some bogus files in the diffstat output such as:
[master] | 177 ++
[master^2~4] | 9
[master^] | 24
[mybranch] | 56
[mybranch^] | 616 +++++++
- Fredrik
^ permalink raw reply
* Re: Handling large files with GIT
From: Junio C Hamano @ 2006-02-14 22:30 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds
In-Reply-To: <Pine.LNX.4.64.0602141357300.3691@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> If somebody is interested in making the "lots of filename changes" case go
> fast, I'd be more than happy to walk them through what they'd need to
> change. I'm just not horribly motivated to do it myself. Hint, hint.
In case anybody is wondering, I share the same feeling. I
cannot say I'd be "more than happy to" clean up potential
breakages during the development of such changes, but if the
change eventually would help certain use cases, I can be
persuaded to help debugging such a mess ;-).
^ permalink raw reply
* Re: several quick questions
From: Junio C Hamano @ 2006-02-14 22:39 UTC (permalink / raw)
To: Carl Worth; +Cc: git, Linus Torvalds
In-Reply-To: <87d5hpvc8p.wl%cworth@cworth.org>
Carl Worth <cworth@cworth.org> writes:
> You've pointed out that branches are free in terms of what git has to
> do. I'm saying that they're not free for the user who bears the cost
> of inventing a name. And in the case of any commit-while-seeking, it's
> at the time of the commit itself that the user has enough information
> to invent a useful name, not prior to seeking, (when the user is still
> trying to figure things out).
I think this is a very valid point and I am happy to accept a
workable proposal (does not have to be a working patch, but a
general semantics that covers most of if not all the corner
cases).
^ 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