* Re: [PATCH 2/5] git-config: add --remote option for reading config from remote repo
From: Sven Verdoolaege @ 2007-05-04 21:10 UTC (permalink / raw)
To: Frank Lichtenheld; +Cc: git
In-Reply-To: <20070504210339.GB30324@planck.djpig.de>
On Fri, May 04, 2007 at 11:03:40PM +0200, Frank Lichtenheld wrote:
>
> Some comments on the documentation:
>
> On Fri, May 04, 2007 at 12:56:40PM +0200, Sven Verdoolaege wrote:
> > +'git-config' [--system | --global | --remote=[<host>:]<directory ]
> > + [type] name [value [value_regex]]
>
> maybe something more like
>
> 'git-config' [ scope ]
Sounds reasonable, although I'd probably say [<scope>].
> > +--remote=[<host>:]<directory
> > + Use remote config instead of the repository .git/config.
> > + Only available for reading options.
>
> Why did you add it to all options in the SYNOPSYS then?
Because I wasn't thinking.
skimo
^ permalink raw reply
* Re: using stgit/guilt for public branches
From: Yann Dirson @ 2007-05-04 21:28 UTC (permalink / raw)
To: Robin Rosenberg
Cc: Josef Sipek, Michael S. Tsirkin, Junio C Hamano, Catalin Marinas,
git, Josef 'Jeff' Sipek
In-Reply-To: <200705040131.17837.robin.rosenberg.lists@dewire.com>
On Fri, May 04, 2007 at 01:31:17AM +0200, Robin Rosenberg wrote:
> fredag 04 maj 2007 skrev Robin Rosenberg:
> > torsdag 03 maj 2007 skrev Yann Dirson:
> > [...]
> > > As for publishing, I use the following config entries to publish my
> > > own stack of patches to stgit. You can see at
> > > http://repo.or.cz/w/stgit/ydirson.git that gitweb shows pretty clearly
> > > the structure of the stack (even though things could surely be made
> > > better).
> > >
> > > I use "git push -f" to publish - maybe the "+" refspec syntax would
> > > work with push, I'll try it next time :)
> > >
> > > [remote "orcz"]
> > > url = git+ssh://ydirson@repo.or.cz/srv/git/stgit/ydirson.git
> > > push = refs/heads/master:refs/heads/master
> > > push = refs/patches/master/*:refs/patches/master/*
> >
> > Beautiful!!
> >
> Would it be possible to push only applied patches, and drop unapplied
> ones?
This would require stgit-level knowledge, so we would need an stgit
command.
Maybe "stg publish" or "stg branch --publish" with the current syntax,
since we already have "push". I'd be in favor of "stg branch push"
for the next-gen syntax, though ;)
> It would only matter when one wants to prune the remote repo
> so it may not be terribly important, but it seems I pushed quite a
> lot of references from old patches that I haven't decided what to do
> with yet and those will get new commit id's anyway.
For now you can delete them manually with "git push remote/ref:".
Best regards,
--
Yann.
^ permalink raw reply
* Re: using stgit/guilt for public branches
From: Yann Dirson @ 2007-05-04 21:37 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Robin Rosenberg, Josef Sipek, Junio C Hamano, Catalin Marinas,
git, Josef 'Jeff' Sipek
In-Reply-To: <20070504052042.GA4829@mellanox.co.il>
On Fri, May 04, 2007 at 08:20:59AM +0300, Michael S. Tsirkin wrote:
> > Quoting Yann Dirson <ydirson@altern.org>:
> > Subject: Re: using stgit/guilt for public branches
> >
> > On Wed, Apr 25, 2007 at 11:37:05PM +0200, Robin Rosenberg wrote:
> > > onsdag 25 april 2007 skrev Josef Sipek:
> > > > On Wed, Apr 25, 2007 at 03:20:49PM +0300, Michael S. Tsirkin wrote:
> > > [...]
> > > > > I am concerned that publishing a git branch managed by stg/guilt
> > > > > would present problems: it seems that every time patches are re-ordered,
> > > > > a patch is re-written or removed, or we update from upstream,
> > > > > everyone who pulls the tree branch will have a hard-to-resolve conflict.
> > > > >
> > > > > Is that really a problem? If so, would it be possible to work around this
> > > > > somehow?
> > > >
> > > > I thought about this problem a while back when I was trying to decide how to
> > > > manage the Unionfs git repository. I came to the conclusion, that there was
> > > > no clean way of doing this (at least not using guilt - I can't really speak
> > > > for stgit, as I don't know how it does things exactly).
> > >
> > > StGit has the same problem. Publishing such a branch is only for viewing if
> > > you want to publish the tip, like the pu branch in the Git repo. You shouldn't
> > > merge from pu either.
> >
> > You are right, in that what can be done with such branches is limited.
> > BUT you can safely "stg branch --create" off any remote stgit stack.
> > Then you can "stg rebase origin/master" to port your stack to the new
> > tip of the remote stack.
>
> OK.
> What happens if someone clones the repo, then reorders patches,
> drops some of them, adds new patches in the middle of the stack?
You can't do that out of the box, since you don't get a real stack
when you clone it, you only get the refs. You would need to uncommit
patches manually, and there will not be much support to help you.
Now you're forcing me to unveil my secret plans :)
1. it would be quite easy to reconstruct a full-fledged stack from
those refs, and since you get the remote patchlogs, we could also
fetch any former version of the patch that would be still available
(more work for "stg clone")
2. if noone beats me to doing that, I'll enhance patchlogs some day to
record branching in patchlogs (eg. from "stg branch --clone" or "stg
pick"), as well as merges (eg. from "stg sync")
Note that proper merging from patchlog history will require working at
the meta-diff (ie. "diffs of diffs of trees") level, just like proper
merging at tree-level requires working at the diff level. I don't
think we have the tools for this yet, so we still have a long way to
go :)
Best regards,
--
Yann.
^ permalink raw reply
* Re: [PATCH 2/5] git-config: add --remote option for reading config from remote repo
From: Frank Lichtenheld @ 2007-05-04 21:35 UTC (permalink / raw)
To: Sven Verdoolaege; +Cc: git
In-Reply-To: <20070504211004.GA1719@liacs.nl>
On Fri, May 04, 2007 at 11:10:05PM +0200, Sven Verdoolaege wrote:
> On Fri, May 04, 2007 at 11:03:40PM +0200, Frank Lichtenheld wrote:
> >
> > Some comments on the documentation:
> >
> > On Fri, May 04, 2007 at 12:56:40PM +0200, Sven Verdoolaege wrote:
> > > +'git-config' [--system | --global | --remote=[<host>:]<directory ]
> > > + [type] name [value [value_regex]]
> >
> > maybe something more like
> >
> > 'git-config' [ scope ]
>
> Sounds reasonable, although I'd probably say [<scope>].
Note that this is inconsistent with the rest of the documentation
(e.g. it says [type], not [<type>]).
> > > +--remote=[<host>:]<directory
> > > + Use remote config instead of the repository .git/config.
> > > + Only available for reading options.
> >
> > Why did you add it to all options in the SYNOPSYS then?
>
> Because I wasn't thinking.
Another small error: You seem to be missing a '>' after each occourence of
'<directory'.
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* [PATCH] Small correction in reading of commit headers
From: Alex Riesen @ 2007-05-04 21:51 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Check if a line of the header has enough characters to possibly
contain the requested prefix.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
Noticed by debugging git-log crash in broken repos with
missing packs. It happened to be up in backtrace.
At the moment the optimization is actually a slow down:
no line in the header is shorter than the only key this
function is ever asked for: encoding. But, in case the
function ever gets asked for something longer, the old
condition is just wrong: it does not take into account
the amount of data in the line when comparing with key.
commit.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/commit.c b/commit.c
index aa7059c..d01833d 100644
--- a/commit.c
+++ b/commit.c
@@ -638,7 +638,9 @@ static char *get_header(const struct commit *commit, const char *key)
next = NULL;
} else
next = eol + 1;
- if (!strncmp(line, key, key_len) && line[key_len] == ' ') {
+ if (eol - line > key_len &&
+ !strncmp(line, key, key_len) &&
+ line[key_len] == ' ') {
int len = eol - line - key_len;
char *ret = xmalloc(len);
memcpy(ret, line + key_len + 1, len - 1);
--
1.5.2.rc1.21.g80e79
^ permalink raw reply related
* [PATCH] Handle return code of parse_commit in revision machinery
From: Alex Riesen @ 2007-05-04 21:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <81b0412b0705041024i43d7fc5ah1967d6a6192dc6ee@mail.gmail.com>
This fixes a crash in broken repositories where random commits
suddenly disappear.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
... For example when loosing one of the packs by renaming it into a
random name while trying to figure out how to protect it from deletion
by "git-repack -a -d". Lesson learned, code fixed, tests passed.
revision.c | 75 +++++++++++++++++++++++++++++++++++++++++------------------
revision.h | 2 +-
2 files changed, 53 insertions(+), 24 deletions(-)
diff --git a/revision.c b/revision.c
index e60a26c..b4c494d 100644
--- a/revision.c
+++ b/revision.c
@@ -318,7 +318,10 @@ static void try_to_simplify_commit(struct rev_info *revs, struct commit *commit)
while ((parent = *pp) != NULL) {
struct commit *p = parent->item;
- parse_commit(p);
+ if (parse_commit(p) < 0)
+ die("cannot simplify commit %s (because of %s)",
+ sha1_to_hex(commit->object.sha1),
+ sha1_to_hex(p->object.sha1));
switch (rev_compare_tree(revs, p->tree, commit->tree)) {
case REV_TREE_SAME:
tree_same = 1;
@@ -347,7 +350,10 @@ static void try_to_simplify_commit(struct rev_info *revs, struct commit *commit)
* IOW, we pretend this parent is a
* "root" commit.
*/
- parse_commit(p);
+ if(parse_commit(p) < 0)
+ die("cannot simplify commit %s (invalid %s)",
+ sha1_to_hex(commit->object.sha1),
+ sha1_to_hex(p->object.sha1));
p->parents = NULL;
}
/* fallthrough */
@@ -362,14 +368,14 @@ static void try_to_simplify_commit(struct rev_info *revs, struct commit *commit)
commit->object.flags |= TREECHANGE;
}
-static void add_parents_to_list(struct rev_info *revs, struct commit *commit, struct commit_list **list)
+static int add_parents_to_list(struct rev_info *revs, struct commit *commit, struct commit_list **list)
{
struct commit_list *parent = commit->parents;
unsigned left_flag;
int add, rest;
if (commit->object.flags & ADDED)
- return;
+ return 0;
commit->object.flags |= ADDED;
/*
@@ -388,7 +394,8 @@ static void add_parents_to_list(struct rev_info *revs, struct commit *commit, st
while (parent) {
struct commit *p = parent->item;
parent = parent->next;
- parse_commit(p);
+ if (parse_commit(p) < 0)
+ return -1;
p->object.flags |= UNINTERESTING;
if (p->parents)
mark_parents_uninteresting(p);
@@ -397,7 +404,7 @@ static void add_parents_to_list(struct rev_info *revs, struct commit *commit, st
p->object.flags |= SEEN;
insert_by_date(p, list);
}
- return;
+ return 0;
}
/*
@@ -409,7 +416,7 @@ static void add_parents_to_list(struct rev_info *revs, struct commit *commit, st
revs->prune_fn(revs, commit);
if (revs->no_walk)
- return;
+ return 0;
left_flag = (commit->object.flags & SYMMETRIC_LEFT);
@@ -418,7 +425,8 @@ static void add_parents_to_list(struct rev_info *revs, struct commit *commit, st
struct commit *p = parent->item;
parent = parent->next;
- parse_commit(p);
+ if (parse_commit(p) < 0)
+ return -1;
p->object.flags |= left_flag;
if (p->object.flags & SEEN)
continue;
@@ -426,6 +434,7 @@ static void add_parents_to_list(struct rev_info *revs, struct commit *commit, st
if (add)
insert_by_date(p, list);
}
+ return 0;
}
static void cherry_pick_list(struct commit_list *list)
@@ -508,7 +517,7 @@ static void cherry_pick_list(struct commit_list *list)
free_patch_ids(&ids);
}
-static void limit_list(struct rev_info *revs)
+static int limit_list(struct rev_info *revs)
{
struct commit_list *list = revs->commits;
struct commit_list *newlist = NULL;
@@ -524,7 +533,8 @@ static void limit_list(struct rev_info *revs)
if (revs->max_age != -1 && (commit->date < revs->max_age))
obj->flags |= UNINTERESTING;
- add_parents_to_list(revs, commit, &list);
+ if (add_parents_to_list(revs, commit, &list) < 0)
+ return -1;
if (obj->flags & UNINTERESTING) {
mark_parents_uninteresting(commit);
if (everybody_uninteresting(list))
@@ -539,6 +549,7 @@ static void limit_list(struct rev_info *revs)
cherry_pick_list(newlist);
revs->commits = newlist;
+ return 0;
}
struct all_refs_cb {
@@ -1227,7 +1238,7 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, const ch
return left;
}
-void prepare_revision_walk(struct rev_info *revs)
+int prepare_revision_walk(struct rev_info *revs)
{
int nr = revs->pending.nr;
struct object_array_entry *e, *list;
@@ -1249,42 +1260,59 @@ void prepare_revision_walk(struct rev_info *revs)
free(list);
if (revs->no_walk)
- return;
+ return 0;
if (revs->limited)
- limit_list(revs);
+ if (limit_list(revs) < 0)
+ return -1;
if (revs->topo_order)
sort_in_topological_order_fn(&revs->commits, revs->lifo,
revs->topo_setter,
revs->topo_getter);
+ return 0;
}
-static int rewrite_one(struct rev_info *revs, struct commit **pp)
+enum rewrite_result
+{
+ rewrite_one_ok,
+ rewrite_one_noparents,
+ rewrite_one_error,
+};
+
+static enum rewrite_result rewrite_one(struct rev_info *revs, struct commit **pp)
{
for (;;) {
struct commit *p = *pp;
if (!revs->limited)
- add_parents_to_list(revs, p, &revs->commits);
+ if (add_parents_to_list(revs, p, &revs->commits) < 0)
+ return rewrite_one_error;
if (p->parents && p->parents->next)
- return 0;
+ return rewrite_one_ok;
if (p->object.flags & (TREECHANGE | UNINTERESTING))
- return 0;
+ return rewrite_one_ok;
if (!p->parents)
- return -1;
+ return rewrite_one_noparents;
*pp = p->parents->item;
}
}
-static void rewrite_parents(struct rev_info *revs, struct commit *commit)
+static int rewrite_parents(struct rev_info *revs, struct commit *commit)
{
struct commit_list **pp = &commit->parents;
while (*pp) {
struct commit_list *parent = *pp;
- if (rewrite_one(revs, &parent->item) < 0) {
+ switch (rewrite_one(revs, &parent->item))
+ {
+ case rewrite_one_ok:
+ break;
+ case rewrite_one_noparents:
*pp = parent->next;
continue;
+ case rewrite_one_error:
+ return -1;
}
pp = &parent->next;
}
+ return 0;
}
static int commit_match(struct commit *commit, struct rev_info *opt)
@@ -1320,7 +1348,8 @@ static struct commit *get_revision_1(struct rev_info *revs)
if (revs->max_age != -1 &&
(commit->date < revs->max_age))
continue;
- add_parents_to_list(revs, commit, &revs->commits);
+ if (add_parents_to_list(revs, commit, &revs->commits) < 0)
+ return NULL;
}
if (commit->object.flags & SHOWN)
continue;
@@ -1348,8 +1377,8 @@ static struct commit *get_revision_1(struct rev_info *revs)
if (!commit->parents || !commit->parents->next)
continue;
}
- if (revs->parents)
- rewrite_parents(revs, commit);
+ if (revs->parents && rewrite_parents(revs, commit) < 0)
+ return NULL;
}
return commit;
} while (revs->commits);
diff --git a/revision.h b/revision.h
index cdf94ad..2845167 100644
--- a/revision.h
+++ b/revision.h
@@ -113,7 +113,7 @@ extern void init_revisions(struct rev_info *revs, const char *prefix);
extern int setup_revisions(int argc, const char **argv, struct rev_info *revs, const char *def);
extern int handle_revision_arg(const char *arg, struct rev_info *revs,int flags,int cant_be_filename);
-extern void prepare_revision_walk(struct rev_info *revs);
+extern int prepare_revision_walk(struct rev_info *revs);
extern struct commit *get_revision(struct rev_info *revs);
extern void mark_parents_uninteresting(struct commit *commit);
--
1.5.2.rc1.21.g80e79
^ permalink raw reply related
* Re: [git-svn PATCH] Fix markup in git-svn man page
From: Junio C Hamano @ 2007-05-04 22:06 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Eric Wong, git
In-Reply-To: <20070504070003.9117.75385.stgit@yoghurt>
Looks sane to me. I did not know about double-semicolon, which
is mentioned in the user guide documentation at the asciidoc
site but I could not tell how it is different from double-colon
form. I am guessing (from the behaviour after applying your
patch) that it allows second level of listing...
^ permalink raw reply
* Re: [RFC?] Telling git about more complex relationships between commits (Was: Re: FFmpeg considering GIT)
From: Alex Riesen @ 2007-05-04 22:11 UTC (permalink / raw)
To: Johan Herland; +Cc: git
In-Reply-To: <200705041353.17992.johan@herland.net>
Johan Herland, Fri, May 04, 2007 13:53:10 +0200:
> As for "Reverts", the commit pointed to should already be in your history,
> since you cannot revert something that hasn't already been applied at an
> earlier point in your history. In other words, the reverted commit will
> automatically be included in your "git gc --prune" or "git clone" regardless
> of the "Reverts" fields, since "Reverts" can only point to an ancestor.
So it becomes useless after rebase
> As for "Cherry-Pick", it's a fairly weak relationship that shouldn't affect
> anything except to give a hint to merge, blame, and similar tools.
In which case, just put it in the message part of commit (in fact, it
was there for some time. And was mostly useless, and got dropped).
And how exactly do you think the tools _can_ use this hint?
Especially merge, which should be absolutely certain about what inputs
and hints gets.
And what use is it for blame? How do you prioritze the hint? Is it
more important than the history (which describes each and every line),
or less? If the hint is more important, than how (and how often) do
you tell the user that the hint was not found (because the commit is
long pruned) and the tool switched back to looking into history.
It's useless.
^ permalink raw reply
* [PATCH] diff format documentation: describe raw combined diff format
From: Jakub Narebski @ 2007-05-04 22:48 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
Add description of raw combined diff format to diff-formats.txt,
as "diff format for merges" section, before "Generating patches..."
section.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
The description of raw combined diff format is based testing the output,
and on what I remember on discussion regarding raw format: the lack of
"score" number (although it should be fairly easy to add it), and path
only for "dst". See for example:
$ git diff-tree -M -c --raw c182ec90d824168cfb70494bb920c0a2fb590d98
I need documentation of raw combined diff format to allow gitweb to show
diff with any parent and diff --cc (or diff -c), not just diff with the
first parent for a merge.
SIDENOTE: in man pages generated using asciidoc 7.1.2 the literal
block used for examples lacks vertical whitespace after block. For
example the following asciidoc code
Example:
------------------------------------------------
::100644 100644 100644 fabadb8... cc95eb0... 4866510... MM describe.c
------------------------------------------------
Note that 'combined diff' lists only files which were modified from
renders as (make doc; man Documentation/git-diff-tree.1)
Example:
::100644 100644 100644 fabadb8... cc95eb0... 4866510... MM describe.c
Note that combined diff lists only files which were modified from
Note no space after example.
Similar formatting is used very common in the git documentation.
I'd try to upgrade asciidoc and see if the problem persists.
Documentation/diff-format.txt | 22 ++++++++++++++++++++++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/Documentation/diff-format.txt b/Documentation/diff-format.txt
index 378e72f..e38a1f1 100644
--- a/Documentation/diff-format.txt
+++ b/Documentation/diff-format.txt
@@ -59,6 +59,28 @@ When `-z` option is not used, TAB, LF, and backslash characters
in pathnames are represented as `\t`, `\n`, and `\\`,
respectively.
+diff format for merges
+----------------------
+
+"git-diff-tree" and "git-diff-files" can take '-c' or '--cc' option
+to generate diff output also for merge commits. The output differs
+from the format described above in the following way:
+
+. there is a colon for each parent
+. there are more "src" modes and "src" sha1
+. status is concatenated status characters for each parent
+. no optional "score" number
+. single path, only for "dst"
+
+Example:
+
+------------------------------------------------
+::100644 100644 100644 fabadb8... cc95eb0... 4866510... MM describe.c
+------------------------------------------------
+
+Note that 'combined diff' lists only files which were modified from
+all parents.
+
Generating patches with -p
--------------------------
--
1.5.1.3
^ permalink raw reply related
* Re: Initial support for cloning submodules
From: Junio C Hamano @ 2007-05-04 22:52 UTC (permalink / raw)
To: Sven Verdoolaege; +Cc: git
In-Reply-To: <11782762032207-git-send-email-skimo@liacs.nl>
The plumbing part looks very good, although I sensed a slight
slop toward the end (will comment on individual patches later).
I do not like the Porcelain part very much, though. I do not
think we would want to add anything new to git-clone. We should
lose as much code from git-clone that is common with git-fetch
as we can first, and add new features to git-fetch, with
possibly passthru options added to git-clone as needed (e.g. a
new --submodule option).
If you --submodule cloned a remote repository when it had two
submodules, and then later the remote adds another submodule,
you would need to have a way to fetch that can discover the
presense of the new submodule and add it for you, and at that
point, having the code that knows much about submodules in clone
would not help you much.
I suspect that a possible interaction between git-fetch and
git-clone would go like this:
(1) "git-clone [--submodules]" would perform a normal clone,
having most of its work done by git-remote and git-fetch;
(2) when "--submodules" is given to "git-clone", it passes it
through to underlying "git-fetch";
(3) "git-fetch --submodules", after finishing what it would do
without "--submodules" option, would inspect the fetched
tree (or the index derived from it), find the tree entries
with mode 160000 (i.e. submodule graft points), and _then_
uses the pathnames of these tree entries to consult the
config mechanism to see which URL(s) can be used to
retrieve them, probably only for new submodules. Your new
"config --remote" mechanism may be one good way to prime
the configuration from the originating site.
We could probably extend the upload-pack protocol to send the
same information as you are using submodules.*.url for, instead
of adding a yet another protocol and program pairs you used for
"git config --remote". Having a generic program and protocol to
dump the whole configuration file is certainly simpler, easier
to debug, and easier to repurpose, it makes me somewhat worried
about security implications (if it is open to http then worrying
about it is not very useful, though).
^ permalink raw reply
* [RFC PATCH] Rename "bury" back to "sink".
From: Yann Dirson @ 2007-05-04 22:53 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
Signed-off-by: Yann Dirson <ydirson@altern.org>
---
Well, it looks like the voices we heard on this naming issue were
quite equally cast towards each of the 2 name.
Let my vote be to get back to "sink", so the user can easily pair the
command with "float". I expect that any previously-silent majoity
prefering "bury" will talk now, before Catalin decides if he wants
this patch in the next release :)
Oh, this patch reminds me we still have to activate rename
detection...
Documentation/stg-bury.txt | 49 -------------------------------
Documentation/stg-sink.txt | 49 +++++++++++++++++++++++++++++++
Documentation/stg.txt | 4 +--
contrib/stgit-completion.bash | 4 +--
stgit/commands/bury.py | 65 -----------------------------------------
stgit/commands/sink.py | 65 +++++++++++++++++++++++++++++++++++++++++
stgit/main.py | 4 +--
7 files changed, 120 insertions(+), 120 deletions(-)
diff --git a/Documentation/stg-bury.txt b/Documentation/stg-bury.txt
deleted file mode 100644
index 22ab548..0000000
--- a/Documentation/stg-bury.txt
+++ /dev/null
@@ -1,49 +0,0 @@
-stg-bury(1)
-===========
-Yann Dirson <ydirson@altern.org>
-v0.13, April 2007
-
-NAME
-----
-stg-bury - stgdesc:bury[]
-
-SYNOPSIS
---------
-[verse]
-'stg' bury [--to=<target>] [--nopush] [<patches>]
-
-DESCRIPTION
------------
-
-This is the opposite operation of stglink:float[]: move the specified
-patches down the stack. It is for example useful to group stable
-patches near the bottom of the stack, where they are less likely to be
-impacted by the push of another patch, and from where they can be more
-easily committed or pushed.
-
-If no patch is specified on command-line, the current patch is buried.
-By default patches are buried at the bottom of the stack, but the
-'--to' option allows to bury under any applied patch.
-
-Buring internally involves popping all patches (or all patches
-including <target patch>), then pushing the patches to bury, and then
-(unless '--nopush' is also given) pushing back into place the
-formerly-applied patches.
-
-
-OPTIONS
--------
-
---to=<TARGET>::
--t <TARGET>::
- Specify a target patch to bury the patches below, instead of
- buring at the bottom of the stack.
-
---nopush::
--n::
- Do not push back on the stack the formerly-applied patches.
- Only the patches to bury are pushed.
-
-StGIT
------
-Part of the StGIT suite - see gitlink:stg[1].
diff --git a/Documentation/stg-sink.txt b/Documentation/stg-sink.txt
new file mode 100644
index 0000000..0f569be
--- /dev/null
+++ b/Documentation/stg-sink.txt
@@ -0,0 +1,49 @@
+stg-sink(1)
+===========
+Yann Dirson <ydirson@altern.org>
+v0.13, April 2007
+
+NAME
+----
+stg-sink - stgdesc:sink[]
+
+SYNOPSIS
+--------
+[verse]
+'stg' sink [--to=<target>] [--nopush] [<patches>]
+
+DESCRIPTION
+-----------
+
+This is the opposite operation of stglink:float[]: move the specified
+patches down the stack. It is for example useful to group stable
+patches near the bottom of the stack, where they are less likely to be
+impacted by the push of another patch, and from where they can be more
+easily committed or pushed.
+
+If no patch is specified on command-line, the current patch gets sunk.
+By default patches are sunk to the bottom of the stack, but the
+'--to' option allows to place them under any applied patch.
+
+Sinking internally involves popping all patches (or all patches
+including <target patch>), then pushing the patches to sink, and then
+(unless '--nopush' is also given) pushing back into place the
+formerly-applied patches.
+
+
+OPTIONS
+-------
+
+--to=<TARGET>::
+-t <TARGET>::
+ Specify a target patch to place the patches below, instead of
+ sinking them to the bottom of the stack.
+
+--nopush::
+-n::
+ Do not push back on the stack the formerly-applied patches.
+ Only the patches to sink are pushed.
+
+StGIT
+-----
+Part of the StGIT suite - see gitlink:stg[1].
diff --git a/Documentation/stg.txt b/Documentation/stg.txt
index cf28b02..af57c37 100644
--- a/Documentation/stg.txt
+++ b/Documentation/stg.txt
@@ -137,8 +137,8 @@ stglink:goto[]::
stgdesc:goto[]
stglink:float[]::
stgdesc:float[]
-stglink:bury[]::
- stgdesc:bury[]
+stglink:sink[]::
+ stgdesc:sink[]
stglink:applied[]::
stgdesc:applied[]
stglink:unapplied[]::
diff --git a/contrib/stgit-completion.bash b/contrib/stgit-completion.bash
index 3c3bf92..760fc2f 100644
--- a/contrib/stgit-completion.bash
+++ b/contrib/stgit-completion.bash
@@ -15,7 +15,6 @@ _stg_commands="
applied
assimilate
branch
- bury
delete
diff
clean
@@ -46,6 +45,7 @@ _stg_commands="
rm
series
show
+ sink
status
sync
top
@@ -190,13 +190,13 @@ _stg ()
# repository commands
id) _stg_patches $command _all_patches ;;
# stack commands
- bury) _stg_patches $command _all_patches ;;
float) _stg_patches $command _all_patches ;;
goto) _stg_patches $command _all_other_patches ;;
hide) _stg_patches $command _all_patches ;;
pop) _stg_patches $command _applied_patches ;;
push) _stg_patches $command _unapplied_patches ;;
series) _stg_patches $command _all_patches ;;
+ sink) _stg_patches $command _all_patches ;;
unhide) _stg_patches $command _all_patches ;;
# patch commands
delete) _stg_patches $command _all_patches ;;
diff --git a/stgit/commands/bury.py b/stgit/commands/bury.py
deleted file mode 100644
index b14f09e..0000000
--- a/stgit/commands/bury.py
+++ /dev/null
@@ -1,65 +0,0 @@
-
-__copyright__ = """
-Copyright (C) 2007, Yann Dirson <ydirson@altern.org>
-
-This program is free software; you can redistribute it and/or modify
-it under the terms of the GNU General Public License version 2 as
-published by the Free Software Foundation.
-
-This program is distributed in the hope that it will be useful,
-but WITHOUT ANY WARRANTY; without even the implied warranty of
-MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-GNU General Public License for more details.
-
-You should have received a copy of the GNU General Public License
-along with this program; if not, write to the Free Software
-Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
-"""
-
-import sys, os
-from optparse import OptionParser, make_option
-
-from stgit.commands.common import *
-from stgit.utils import *
-from stgit import stack, git
-
-
-help = 'bury patches down the stack'
-usage = """%prog [-t <target patch>] [-n] [<patches>]
-
-Pop all patches (or all patches including <target patch>), then
-push the specified <patches> (the current patch by default), and
-then push back into place the formerly-applied patches (unless -n
-is also given)."""
-
-options = [make_option('-n', '--nopush',
- help = 'do not push the patches back after sinking',
- action = 'store_true'),
- make_option('-t', '--to', metavar = 'TARGET',
- help = 'bury patches below TARGET patch')]
-
-def func(parser, options, args):
- """Bury patches
- """
-
- check_local_changes()
- check_conflicts()
- check_head_top_equal()
-
- oldapplied = crt_series.get_applied()
- unapplied = crt_series.get_unapplied()
- all = unapplied + oldapplied
-
- if len(args) > 0:
- patches = parse_patches(args, all)
- else:
- patches = [ crt_series.get_current() ]
-
- crt_series.pop_patch(options.to or oldapplied[0])
- push_patches(patches)
-
- if not options.nopush:
- newapplied = crt_series.get_applied()
- def not_reapplied_yet(p):
- return not p in newapplied
- push_patches(filter(not_reapplied_yet, oldapplied))
diff --git a/stgit/commands/sink.py b/stgit/commands/sink.py
new file mode 100644
index 0000000..85cc70f
--- /dev/null
+++ b/stgit/commands/sink.py
@@ -0,0 +1,65 @@
+
+__copyright__ = """
+Copyright (C) 2007, Yann Dirson <ydirson@altern.org>
+
+This program is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License version 2 as
+published by the Free Software Foundation.
+
+This program is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with this program; if not, write to the Free Software
+Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+"""
+
+import sys, os
+from optparse import OptionParser, make_option
+
+from stgit.commands.common import *
+from stgit.utils import *
+from stgit import stack, git
+
+
+help = 'send patches deeper down the stack'
+usage = """%prog [-t <target patch>] [-n] [<patches>]
+
+Pop all patches (or all patches including <target patch>), then
+push the specified <patches> (the current patch by default), and
+then push back into place the formerly-applied patches (unless -n
+is also given)."""
+
+options = [make_option('-n', '--nopush',
+ help = 'do not push the patches back after sinking',
+ action = 'store_true'),
+ make_option('-t', '--to', metavar = 'TARGET',
+ help = 'sink patches below TARGET patch')]
+
+def func(parser, options, args):
+ """Sink patches down the stack.
+ """
+
+ check_local_changes()
+ check_conflicts()
+ check_head_top_equal()
+
+ oldapplied = crt_series.get_applied()
+ unapplied = crt_series.get_unapplied()
+ all = unapplied + oldapplied
+
+ if len(args) > 0:
+ patches = parse_patches(args, all)
+ else:
+ patches = [ crt_series.get_current() ]
+
+ crt_series.pop_patch(options.to or oldapplied[0])
+ push_patches(patches)
+
+ if not options.nopush:
+ newapplied = crt_series.get_applied()
+ def not_reapplied_yet(p):
+ return not p in newapplied
+ push_patches(filter(not_reapplied_yet, oldapplied))
diff --git a/stgit/main.py b/stgit/main.py
index 9c319c6..1a1f534 100644
--- a/stgit/main.py
+++ b/stgit/main.py
@@ -63,7 +63,6 @@ commands = Commands({
'applied': 'applied',
'assimilate': 'assimilate',
'branch': 'branch',
- 'bury': 'bury',
'delete': 'delete',
'diff': 'diff',
'clean': 'clean',
@@ -94,6 +93,7 @@ commands = Commands({
'rm': 'rm',
'series': 'series',
'show': 'show',
+ 'sink': 'sink',
'status': 'status',
'sync': 'sync',
'top': 'top',
@@ -111,7 +111,6 @@ stackcommands = (
'applied',
'assimilate',
'branch',
- 'bury',
'clean',
'commit',
'float',
@@ -124,6 +123,7 @@ stackcommands = (
'push',
'rebase',
'series',
+ 'sink',
'top',
'unapplied',
'uncommit',
^ permalink raw reply related
* Re: using stgit/guilt for public branches
From: Yann Dirson @ 2007-05-04 23:12 UTC (permalink / raw)
To: Robin Rosenberg
Cc: Josef Sipek, Michael S. Tsirkin, Junio C Hamano, Catalin Marinas,
git, Josef 'Jeff' Sipek
In-Reply-To: <20070503205836.GA19253@nan92-1-81-57-214-146.fbx.proxad.net>
On Thu, May 03, 2007 at 10:58:36PM +0200, Yann Dirson wrote:
> As for publishing, I use the following config entries to publish my
> own stack of patches to stgit. You can see at
> http://repo.or.cz/w/stgit/ydirson.git that gitweb shows pretty clearly
> the structure of the stack (even though things could surely be made
> better).
Let's make things even more fun: I have now moved a couple of patches
(testsuite cases to demonstrate bugs still to be fixed) to a new stack
so they don't get pulled by error. This stack itself is forked off my
master stack, and I just have to "stg pull" to get it rebased to the
new master head (requires stgit head, not in 0.12*):
[branch "bugs.stgit"]
pull-policy = rebase
parentbranch = master
> I use "git push -f" to publish - maybe the "+" refspec syntax would
> work with push, I'll try it next time :)
It indeed works as expected, so the final syntax is as follows, so
"git push orcz" is now sufficient to publish everything, and you can
now fork your own stack off my remote "bugs" stack, which itself
forked off my "master" stack - enjoy :)
[remote "orcz"]
url = git+ssh://ydirson@repo.or.cz/srv/git/stgit/ydirson.git
fetch = +refs/heads/*:refs/remotes/orcz/*
push = +refs/heads/master:refs/heads/master
push = +refs/patches/master/*:refs/patches/master/*
push = +refs/heads/bugs:refs/heads/bugs
push = +refs/patches/bugs/*:refs/patches/bugs/*
Best regards,
--
Yann.
^ permalink raw reply
* Re: [RFC PATCH] Rename "bury" back to "sink".
From: Jakub Narebski @ 2007-05-04 23:22 UTC (permalink / raw)
To: git
In-Reply-To: <20070504224639.26133.6157.stgit@gandelf.nowhere.earth>
Yann Dirson wrote:
> Well, it looks like the voices we heard on this naming issue were
> quite equally cast towards each of the 2 name.
>
> Let my vote be to get back to "sink", so the user can easily pair the
> command with "float". I expect that any previously-silent majoity
> prefering "bury" will talk now, before Catalin decides if he wants
> this patch in the next release :)
I'm rather partial to "bury" rather than "sink", as "bury" has the
notation of going deeper (like "float" has notation of guing up, to
the surface), while "sink" does not need to. Additionally "sink" is
a noun as well as a verb.
> Oh, this patch reminds me we still have to activate rename
> detection...
True.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Support ent:relative_path
From: Jakub Narebski @ 2007-05-04 23:36 UTC (permalink / raw)
To: git
In-Reply-To: <7vabwktsng.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> (soon after 1.5.2)
>
> - start accepting "<something>:./<path>" as "relative to where I am".
> - start accepting "<something>:?<string>" as "look back to find
> the string".
> - clearly explain the plan and prepare the users.
>
> (a big release in the future, perhaps 1.6.0)
>
> - "<something>:<path>" becomes relative to where you are.
> - stop "<something>:/<string>" and start "<something>:/<fullpath>".
I'm not sure about "<tree-ish>:<path>" with <path> being relative by
default. For me it is <path> in <tree-ish> (like in
"git-ls-tree -r <tree-ish>" result).
The "<tree-ish>:./<path>" is a good syntax I think.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [StGIT RFC PATCH] Activate rename detection by default.
From: Yann Dirson @ 2007-05-04 23:54 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
This patch uses -M when generating diffs, which then looks fine, just
like any other git-generated diff.
While I was at it, I also added -M when calling "stg files" or "stg
status". While we need that for completeness, we currently just
display the raw git-diff-tree output, and it may break some scripts.
We may also want to make it more human-readable (not sure how, esp. if
we want to remain machine-parsable).
It also raises the issue of whether to activate this by default or not
(mostly in status and files), and how to select this behaviour -
something which will possibly be needed to be decided before
introducing -C and --find-copies-harder, which would be useful as
well, the latter being definitely a candidate to be off by default.
That gives:
$ ./stg status
? contrib/stg-push-force
R100 README README2
M stgit/git.py
$ ./stg files sink
R056 Documentation/stg-bury.txt Documentation/stg-sink.txt
M Documentation/stg.txt
M contrib/stgit-completion.bash
R093 stgit/commands/bury.py stgit/commands/sink.py
M stgit/main.py
Signed-off-by: Yann Dirson <ydirson@altern.org>
---
README2 | 0
stgit/git.py | 12 ++++++------
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/README b/README2
similarity index 100%
rename from README
rename to README2
diff --git a/stgit/git.py b/stgit/git.py
index d7eb48e..ed09eca 100644
--- a/stgit/git.py
+++ b/stgit/git.py
@@ -255,7 +255,7 @@ def __tree_status(files = None, tree_id = 'HEAD', unknown = False,
cache_files += [('C', filename) for filename in conflicts]
# the rest
- for line in _output_lines(['git-diff-index', tree_id, '--'] + files):
+ for line in _output_lines(['git-diff-index', '-M', tree_id, '--'] + files):
fs = tuple(line.rstrip().split(' ',4)[-1].split('\t',1))
if fs[1] not in conflicts:
cache_files.append(fs)
@@ -774,13 +774,13 @@ def diff(files = None, rev1 = 'HEAD', rev2 = None, out_fd = None):
files = []
if rev1 and rev2:
- diff_str = _output(['git-diff-tree', '-p', rev1, rev2, '--'] + files)
+ diff_str = _output(['git-diff-tree', '-M', '-p', rev1, rev2, '--'] + files)
elif rev1 or rev2:
refresh_index()
if rev2:
- diff_str = _output(['git-diff-index', '-p', '-R', rev2, '--'] + files)
+ diff_str = _output(['git-diff-index', '-M', '-p', '-R', rev2, '--'] + files)
else:
- diff_str = _output(['git-diff-index', '-p', rev1, '--'] + files)
+ diff_str = _output(['git-diff-index', '-M', '-p', rev1, '--'] + files)
else:
diff_str = ''
@@ -808,7 +808,7 @@ def files(rev1, rev2):
"""
result = ''
- for line in _output_lines('git-diff-tree -r %s %s' % (rev1, rev2)):
+ for line in _output_lines('git-diff-tree -M -r %s %s' % (rev1, rev2)):
result += '%s %s\n' % tuple(line.rstrip().split(' ',4)[-1].split('\t',1))
return result.rstrip()
@@ -826,7 +826,7 @@ def barefiles(rev1, rev2):
def pretty_commit(commit_id = 'HEAD'):
"""Return a given commit (log + diff)
"""
- return _output(['git-diff-tree', '--cc', '--always', '--pretty', '-r',
+ return _output(['git-diff-tree', '-M', '--cc', '--always', '--pretty', '-r',
commit_id])
def checkout(files = None, tree_id = None, force = False):
^ permalink raw reply related
* Re: [PATCH] Support ent:relative_path
From: Junio C Hamano @ 2007-05-05 0:04 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <f1gg1o$p52$2@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> I'm not sure about "<tree-ish>:<path>" with <path> being relative by
> default. For me it is <path> in <tree-ish> (like in
> "git-ls-tree -r <tree-ish>" result).
That's right (and Dscho is also).
"v1.5.1:git.c" IS "git.c that appears at the toplevel of
v1.5.1's tree."
Ok, for now let's forget about this relative stuff.
^ permalink raw reply
* [PATCH v3] Support ent:relative_path
From: Dana How @ 2007-05-05 0:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, danahow
Most commands accept relative paths, but this is
not true of arguments in ent:path format. This
patch makes all of the following git-show commands
work in the git source tree (not just the first):
% cd xdiff
% git-show v1.5.2-rc0:xdiff/xemit.h
% git-show v1.5.2-rc0:./xemit.h
% git-show v1.5.2-rc0:../sha1_name.c
It also adds ent:?string as a synonym for ent:/string .
This makes the following changes possible later:
ent:/path is an absolute path and ent:path is relative.
Signed-off-by: Dana L. How <danahow@gmail.com>
---
cache.h | 1 +
setup.c | 5 +++-
sha1_name.c | 78 +++++++++++++++++++++++++++++++++++++++++++++++++++++++---
3 files changed, 79 insertions(+), 5 deletions(-)
diff --git a/cache.h b/cache.h
index 8e76152..53507d9 100644
--- a/cache.h
+++ b/cache.h
@@ -215,6 +215,7 @@ extern char *get_graft_file(void);
#define ALTERNATE_DB_ENVIRONMENT "GIT_ALTERNATE_OBJECT_DIRECTORIES"
+extern const char *prefix_to_cwd;
extern const char **get_pathspec(const char *prefix, const char **pathspec);
extern const char *setup_git_directory_gently(int *);
extern const char *setup_git_directory(void);
diff --git a/setup.c b/setup.c
index a45ea83..46ae6e3 100644
--- a/setup.c
+++ b/setup.c
@@ -1,5 +1,7 @@
#include "cache.h"
+const char *prefix_to_cwd;
+
const char *prefix_path(const char *prefix, int len, const char *path)
{
const char *orig = path;
@@ -252,7 +254,8 @@ const char *setup_git_directory_gently(int *nongit_ok)
cwd[len++] = '/';
cwd[len] = 0;
inside_git_dir = !prefixcmp(cwd + offset, ".git/");
- return cwd + offset;
+ prefix_to_cwd = cwd + offset;
+ return prefix_to_cwd;
}
int git_config_perm(const char *var, const char *value)
diff --git a/sha1_name.c b/sha1_name.c
index 55f25a2..dd415c1 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -593,6 +593,67 @@ static int handle_one_ref(const char *path,
}
/*
+ * Future: nonzero to assume relative paths
+ */
+#define ENT_COLON_ASSUME_RELATIVE 0
+
+/*
+ * Modify path into a full absolute path with no leading "/"
+ * and no "." or "..". If we can't,
+ * leave input unaltered for client's error message.
+ */
+static void prepend_prefix(const char **cp, int *namelen)
+{
+ char *t, *t2;
+ const char *cp2 = *cp;
+ int type, namelen2 = *namelen;
+ static char fullpath[PATH_MAX];
+ int fixup = strstr(cp2, "/./") || strstr(cp2, "/../");
+ for (type = 4; --type > 0; )
+ if (namelen2 > type && !memcmp(cp2, "../" + 3 - type, type))
+ break;
+
+ /* handle simple cases else create absolute path */
+ fullpath[0] = 0;
+ if ((type == 0 && !ENT_COLON_ASSUME_RELATIVE) || type == 1) {
+ if (!fixup) goto done;
+ } else
+ if (prefix_to_cwd) {
+ namelen2 += strlen(prefix_to_cwd);
+ if (namelen2 >= PATH_MAX)
+ die("path too long");
+ strcpy(fullpath, prefix_to_cwd);
+ type = 0;
+ } else
+ if (type == 2) {
+ if (!fixup) goto done;
+ } else
+ if (type == 3)
+ return; /* client will complain */
+ cp2 = strcat(fullpath, cp2);
+
+ while ((t = strstr(cp2, "/./")) != NULL)
+ memmove(t, t + 2, (namelen2 -= 2) - (t - cp2) + 1);
+
+ while ((t = strstr(cp2, "/../")) != NULL) {
+ if (t == cp2 || (t == cp2 + 1 && t[-1] == '.'))
+ return; /* client will complain */
+ for (t2 = t; --t2 >= cp2 && *t2 != '/'; )
+ /* nothing */;
+ if (t2 < cp2) {
+ namelen2 -= t + 4 - cp2;
+ cp2 = t + 4;
+ } else {
+ memmove(t2, t + 3, namelen2 - (t + 3 - cp2) + 1);
+ namelen2 -= t + 3 - t2;
+ }
+ }
+
+done: *cp = cp2 + type;
+ *namelen = namelen2 - type;
+}
+
+/*
* This interprets names like ':/Initial revision of "git"' by searching
* through history and returning the first commit whose message starts
* with the given string.
@@ -647,6 +708,11 @@ int get_sha1(const char *name, unsigned char *sha1)
return get_sha1_with_mode(name, sha1, &unused);
}
+/*
+ * Future: change to '?'
+ */
+#define ENT_COLON_OLD_SEARCH '/'
+
int get_sha1_with_mode(const char *name, unsigned char *sha1, unsigned *mode)
{
int ret, bracket_depth;
@@ -666,7 +732,8 @@ int get_sha1_with_mode(const char *name, unsigned char *sha1, unsigned *mode)
int stage = 0;
struct cache_entry *ce;
int pos;
- if (namelen > 2 && name[1] == '/')
+ if (namelen > 2 &&
+ (name[1] == ENT_COLON_OLD_SEARCH || name[1] == '?'))
return get_sha1_oneline(name + 2, sha1);
if (namelen < 3 ||
name[2] != ':' ||
@@ -681,6 +748,7 @@ int get_sha1_with_mode(const char *name, unsigned char *sha1, unsigned *mode)
read_cache();
if (active_nr < 0)
return -1;
+ prepend_prefix(&cp, &namelen);
pos = cache_name_pos(cp, namelen);
if (pos < 0)
pos = -pos - 1;
@@ -708,9 +776,11 @@ int get_sha1_with_mode(const char *name, unsigned char *sha1, unsigned *mode)
}
if (*cp == ':') {
unsigned char tree_sha1[20];
- if (!get_sha1_1(name, cp-name, tree_sha1))
- return get_tree_entry(tree_sha1, cp+1, sha1,
- mode);
+ if (!get_sha1_1(name, cp - name, tree_sha1)) {
+ namelen -= ++cp - name;
+ prepend_prefix(&cp, &namelen);
+ return get_tree_entry(tree_sha1, cp, sha1, mode);
+ }
}
return ret;
}
--
1.5.2.rc0.787.g0014
^ permalink raw reply related
* Re: [PATCH] Support ent:relative_path
From: Dana How @ 2007-05-05 0:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git, danahow
In-Reply-To: <7vy7k4p24s.fsf@assigned-by-dhcp.cox.net>
On 5/4/07, Junio C Hamano <junkio@cox.net> wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
> > I'm not sure about "<tree-ish>:<path>" with <path> being relative by
> > default. For me it is <path> in <tree-ish> (like in
> > "git-ls-tree -r <tree-ish>" result).
>
> That's right (and Dscho is also).
>
> "v1.5.1:git.c" IS "git.c that appears at the toplevel of
> v1.5.1's tree."
>
> Ok, for now let's forget about this relative stuff.
Hmm, most of the work I do in the parts of our
perforce repository I want to convert to git is
far enough down that the paths have 6 in-repo path components.
I don't want to type all those when I want to fetch an
older version with git-show. Everything I do is relative.
In fact, I think perforce supports typing absolute paths,
(using an 8-character prefix!) but I have never used it,
nor would I if it were shorter.
--
Dana L. How danahow@gmail.com +1 650 804 5991 cell
^ permalink raw reply
* Re: [PATCH] Support ent:relative_path
From: Jakub Narebski @ 2007-05-05 1:06 UTC (permalink / raw)
To: Dana How; +Cc: Junio C Hamano, git
In-Reply-To: <56b7f5510705041752o74b59284x872480e4413f83ab@mail.gmail.com>
Dana How wrote:
> On 5/4/07, Junio C Hamano <junkio@cox.net> wrote:
>> Jakub Narebski <jnareb@gmail.com> writes:
>>> I'm not sure about "<tree-ish>:<path>" with <path> being relative by
>>> default. For me it is <path> in <tree-ish> (like in
>>> "git-ls-tree -r <tree-ish>" result).
>>
>> That's right (and Dscho is also).
>>
>> "v1.5.1:git.c" IS "git.c that appears at the toplevel of
>> v1.5.1's tree."
>>
>> Ok, for now let's forget about this relative stuff.
>
> Hmm, most of the work I do in the parts of our
> perforce repository I want to convert to git is
> far enough down that the paths have 6 in-repo path components.
> I don't want to type all those when I want to fetch an
> older version with git-show. Everything I do is relative.
> In fact, I think perforce supports typing absolute paths,
> (using an 8-character prefix!) but I have never used it,
> nor would I if it were shorter.
I think the consensus is to use <tree-ish>:./<relative-path> for
relative paths, and <tree-ish>:<path> for absolute (well, in the
meaning that it counts from top of _tree-ish_, and tree-ish needs
not to be top tree / commit tree).
And I think 6 in-repo path components means not very well thought
directory hierarchy, I think...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH v3] Support ent:relative_path
From: Jakub Narebski @ 2007-05-05 1:11 UTC (permalink / raw)
To: git
In-Reply-To: <463BD40C.6080909@gmail.com>
Dana How wrote:
> Most commands accept relative paths, but this is
> not true of arguments in ent:path format. This
> patch makes all of the following git-show commands
> work in the git source tree (not just the first):
>
> % cd xdiff
> % git-show v1.5.2-rc0:xdiff/xemit.h
> % git-show v1.5.2-rc0:./xemit.h
> % git-show v1.5.2-rc0:../sha1_name.c
>
> It also adds ent:?string as a synonym for ent:/string .
> This makes the following changes possible later:
> ent:/path is an absolute path and ent:path is relative.
First, we now usually use 'tree-ish' or 'treeish', not 'ent'.
Second, it is ':/<text>', not '<tree-ish>:/<text>'
git-rev-parse(1):
* A colon, followed by a slash, followed by a text: this names
a commit whose commit message starts with the specified text.
This name returns the youngest matching commit which is
reachable from any ref. If the commit message starts with a
'!', you have to repeat that; the special sequence ':/!',
followed by something else than '!' is reserved for now.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Support ent:relative_path
From: Junio C Hamano @ 2007-05-05 1:15 UTC (permalink / raw)
To: Dana How; +Cc: Jakub Narebski, git
In-Reply-To: <56b7f5510705041752o74b59284x872480e4413f83ab@mail.gmail.com>
"Dana How" <danahow@gmail.com> writes:
> On 5/4/07, Junio C Hamano <junkio@cox.net> wrote:
>> Jakub Narebski <jnareb@gmail.com> writes:
>> > I'm not sure about "<tree-ish>:<path>" with <path> being relative by
>> > default. For me it is <path> in <tree-ish> (like in
>> > "git-ls-tree -r <tree-ish>" result).
>>
>> That's right (and Dscho is also).
>>
>> "v1.5.1:git.c" IS "git.c that appears at the toplevel of
>> v1.5.1's tree."
>>
>> Ok, for now let's forget about this relative stuff.
>
> Hmm, most of the work I do in the parts of our
> perforce repository I want to convert to git is
> far enough down...
The key word in my statement is "for now". I simply declared
that I do not want to think about it further until 1.5.2 final,
that's all.
I am not opposed to give an escape hatch for your problem; I am
quite in favor of that, and I think Alex/J6t's "./" syntax is a
reasonable compromise.
^ permalink raw reply
* Re: [PATCH v3] Support ent:relative_path
From: Johannes Schindelin @ 2007-05-05 1:29 UTC (permalink / raw)
To: Dana How; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <463BD40C.6080909@gmail.com>
Hi,
On Fri, 4 May 2007, Dana How wrote:
> Most commands accept relative paths, but this is
> not true of arguments in ent:path format. This
> patch makes all of the following git-show commands
> work in the git source tree (not just the first):
> % cd xdiff
> % git-show v1.5.2-rc0:xdiff/xemit.h
> % git-show v1.5.2-rc0:./xemit.h
> % git-show v1.5.2-rc0:../sha1_name.c
ACK.
> It also adds ent:?string as a synonym for ent:/string .
> This makes the following changes possible later:
> ent:/path is an absolute path and ent:path is relative.
NACK. The "?" thing is highly unintuitive, and I still do not think that
it is worth the confusion to make Git behave funny on
<tree>:<file-name>.
Think of the "todo" branch, for example. And this is not even far fetched.
In many repositories I have to have separate related, but non-branch
HEADs. For example, I track some projects with custom scripts. These
scripts do _not_ belong into that branch. However, they are related, so I
store them in the same repository.
Plus, my example of the bare-repository still has not been answered by
_anyone_ in favour of changing the current behaviour.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH v3] Support ent:relative_path
From: Shawn O. Pearce @ 2007-05-05 3:30 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Dana How, Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0705050324580.4015@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Fri, 4 May 2007, Dana How wrote:
>
> > Most commands accept relative paths, but this is
> > not true of arguments in ent:path format. This
> > patch makes all of the following git-show commands
> > work in the git source tree (not just the first):
> > % cd xdiff
> > % git-show v1.5.2-rc0:xdiff/xemit.h
> > % git-show v1.5.2-rc0:./xemit.h
> > % git-show v1.5.2-rc0:../sha1_name.c
>
> ACK.
Double ACK. I'm in complete agreement with every point Dscho has
made in this thread, even if I haven't quoted it. ;-)
I *really* do not want to see "<tree-ish>:<path>" to mean include
the current prefix, *especially* when a bare repository is involved.
I often either do ad-hoc git-show lines against bare repositories,
or have scripts that depend on this existing absolute path behavior.
I'd like to see those not break. ;-)
Since "." and ".." should not be valid names in any tree of a Git
repository I think we're OK to say that ":./" and ":../" are to
imply relative to current prefix. But if we do ":../" then we also
have to do ":../../../../../../.." ;-)
--
Shawn.
^ permalink raw reply
* Re: [PATCH v3] Support ent:relative_path
From: Junio C Hamano @ 2007-05-05 3:38 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Dana How, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0705050324580.4015@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Think of the "todo" branch, for example. And this is not even far fetched.
> In many repositories I have to have separate related, but non-branch
> HEADs. For example, I track some projects with custom scripts. These
> scripts do _not_ belong into that branch. However, they are related, so I
> store them in the same repository.
I said I won't talk about it until 1.5.2 final, but you forced
me into it.
> Plus, my example of the bare-repository still has not been answered by
> _anyone_ in favour of changing the current behaviour.
I am not sure if there is anything to answer on this one.
When you are talking to a bare-repository, your place relative
to the root of the working tree is clearly undefined, and it is
natural that "<tree-ish>:./<path>", "<tree-ish>:/<path>" and
"<tree-ish>:<path>" cannot mean anything but relative to the
root of the tree-ish. "<tree-ish>:../<path>" is obviously
nonsense. So it does not matter if unadorned <path> is relative
to cwd or root in this case.
Your other example, however, gives a much better illustration.
An unrelated 'todo' branch where your cwd does not have any
relevance to the contents of that tree-ish, or worse yet, a
commit from git-gui project in git.git repository, where taking
your cwd into account has an actively wrong effect, demonstrates
why we would need a way to say "By this path, I mean from the
top, I do not want you to take it as relative to where I am".
One way to ensure that is to keep the current "it is a path from
the top" behaviour, and extended it with "... unless it begins
with ./". Doing this forever however penalizes the case where
you want to use relative paths by requiring ./ at the beginning.
Another is to do the usual POSIXy path interpretation and
"unless it begins with /, it is taken as relative to where you
are". This penalizes the 'todo' and git-gui commit use case
because the user explicitly needs to say "where I am does not
matter" by prefixing the path with '/', and also necessitates a
change to the syntax for looking backwards for a commit with
that message, because the existing syntax to look for a string
clashes with it [*1*].
Both have merits and demerits. If we did not have any existing
code and users, the latter is clearly what we would have done,
as it is more consistent. The path handling feels more natural
(in line with the way we expect paths to be handled on POSIX
systems), the "look backwards" search feels more natural ( you
use '/' for forward search, '?' for backwards).
I also suspect the latter is more often convenient. When
working on a flat project, it does not matter if the default is
relative to cwd or to the root. But if your project is deep,
and if you somehow do "git show" more often than "git diff" (I
don't, but different people may do so for different reasons), it
would start to hurt if you always have to say "./".
It is however clearly a bigger change to existing users.
Correcting earlier mistakes is painful, so it certainly is
tempting to take the approach that the path is always absolute
and require "./" for relative. I agree it is an easier change,
but I am not convinced yet that it is the right design in the
longer term.
[Footnote]
*1* This is only true for looking for a path in the index case,
as <commit>:/<string> does not seem to work. I think this is a
bug in the current code -- shouldn't it limit the search to
commits that are reachable from that named one?
^ permalink raw reply
* Re: [PATCH] Have git-revert, git-cherry-pick cleanup ./.msg upon successful completion.
From: Shawn O. Pearce @ 2007-05-05 3:46 UTC (permalink / raw)
To: Gerrit Pape; +Cc: git, Alex Riesen
In-Reply-To: <20070504143210.8690.qmail@a4171e0dbe98e3.315fe32.mid.smarden.org>
Gerrit Pape <pape@smarden.org> wrote:
> git-revert and git-cherry-pick left behind the commit message file ./.msg,
> have them use the -f option to git-commit to properly cleanup the
> automatically created file.
I'm actually sort of against changing the behavior of git-commit
-f to mean "delete the file". We never did that before. Users
might get surprised when their file goes away!
What about this change instead? We make cherry-pick/revert
use the same temporary file as merge, which is under .git/
(something Alex mentioned he wanted). I think the use of ".msg"
in cherry-pick/revert has always just been a bug, and not a feature,
so I'm really not against changing things around like this.
diff --git a/builtin-revert.c b/builtin-revert.c
index 4ba0ee6..67c13a3 100644
--- a/builtin-revert.c
+++ b/builtin-revert.c
@@ -237,6 +237,7 @@ static int revert_or_cherry_pick(int argc, const char **argv)
int i;
char *oneline, *reencoded_message = NULL;
const char *message, *encoding;
+ const char *defmsg = git_path("MERGE_MSG");
git_config(git_default_config);
me = action == REVERT ? "revert" : "cherry-pick";
@@ -280,7 +281,7 @@ static int revert_or_cherry_pick(int argc, const char **argv)
* reverse of it if we are revert.
*/
- msg_fd = hold_lock_file_for_update(&msg_file, ".msg", 1);
+ msg_fd = hold_lock_file_for_update(&msg_file, defmsg, 1);
encoding = get_encoding(message);
if (!encoding)
@@ -330,7 +331,6 @@ static int revert_or_cherry_pick(int argc, const char **argv)
sha1_to_hex(head), "HEAD",
sha1_to_hex(next->object.sha1), oneline) ||
write_tree(head, 0, NULL)) {
- const char *target = git_path("MERGE_MSG");
add_to_msg("\nConflicts:\n\n");
read_cache();
for (i = 0; i < active_nr;) {
@@ -345,10 +345,7 @@ static int revert_or_cherry_pick(int argc, const char **argv)
}
}
if (close(msg_fd) || commit_lock_file(&msg_file) < 0)
- die ("Error wrapping up .msg");
- unlink(target);
- if (rename(".msg", target))
- die ("Could not move .msg to %s", target);
+ die ("Error wrapping up %s", defmsg);
fprintf(stderr, "Automatic %s failed. "
"After resolving the conflicts,\n"
"mark the corrected paths with 'git-add <paths>'\n"
@@ -362,7 +359,7 @@ static int revert_or_cherry_pick(int argc, const char **argv)
exit(1);
}
if (close(msg_fd) || commit_lock_file(&msg_file) < 0)
- die ("Error wrapping up .msg");
+ die ("Error wrapping up %s", defmsg);
fprintf(stderr, "Finished one %s.\n", me);
/*
@@ -376,11 +373,9 @@ static int revert_or_cherry_pick(int argc, const char **argv)
if (!no_commit) {
if (edit)
- return execl_git_cmd("commit", "-n", "-F", ".msg",
- "-e", NULL);
+ return execl_git_cmd("commit", "-n", NULL);
else
- return execl_git_cmd("commit", "-n", "-F", ".msg",
- NULL);
+ return execl_git_cmd("commit", "-n", "-F", defmsg, NULL);
}
if (reencoded_message)
free(reencoded_message);
--
Shawn.
^ permalink raw reply related
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