* Re: [PATCH] git-explain
From: J. Bruce Fields @ 2006-12-05 21:00 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Nicolas Pitre, git, Linus Torvalds
In-Reply-To: <Pine.LNX.4.63.0612050950450.28348@wbgn013.biozentrum.uni-wuerzburg.de>
On Tue, Dec 05, 2006 at 09:58:25AM +0100, Johannes Schindelin wrote:
> On Mon, 4 Dec 2006, Junio C Hamano wrote:
> > "J. Bruce Fields" <bfields@fieldses.org> writes:
> >
> > > On Mon, Dec 04, 2006 at 10:55:49PM -0500, Nicolas Pitre wrote:
> > >> ...
> > >> > [PATCH] git-explain
> > >> > ...
> > >>
> > >> What about calling it git-whatsup instead?
> > >
> > > No, clearly it should be git-wtf.
> >
> > Should I take these responses to mean that you two are negative
> > about the approach [...]
>
> I think they just were in the mood for some slashdot style
> unimportant-aspects-in-a-funny-way discussion.
Yeah, I was just being silly, apologies.
^ permalink raw reply
* [PATCH] xdl_merge(): fix and simplify conflict handling
From: Johannes Schindelin @ 2006-12-05 21:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Ramsay Jones, git
In-Reply-To: <7vac22glzz.fsf@assigned-by-dhcp.cox.net>
Suppose you have changes in new1 to the original lines 10-20,
and changes in new2 to the original lines 15-25, then the
changes to 10-25 conflict. But it is possible that the next
changes in new1 still overlap with this change to new2.
So, in the next iteration we have to look at the same change
to new2 again.
The old code tried to be a bit too clever. The new code is
shorter and more to the point: do not fiddle with the ranges
at all.
Also, xdl_append_merge() tries harder to combine conflicts.
This is necessary, because with the above simplification,
some conflicts would not be recognized as conflicts otherwise:
In the above scenario, it is possible that there is no other
change to new1. Absent the combine logic, the change in new2
would be recorded _again_, but as a non-conflict.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
On Tue, 5 Dec 2006, Junio C Hamano wrote:
> However, the conflict 'next' leaves seems a bit suspicious.
> Trying to reproduce
>
> 56f9686c4d1e1d586b731b815bd98d70f84ecda4
>
> gives an interesting illustration.
This is fixed now.
xdiff/xmerge.c | 21 +++++----------------
1 files changed, 5 insertions(+), 16 deletions(-)
diff --git a/xdiff/xmerge.c b/xdiff/xmerge.c
index 1fe7a1b..352207e 100644
--- a/xdiff/xmerge.c
+++ b/xdiff/xmerge.c
@@ -38,8 +38,9 @@ static int xdl_append_merge(xdmerge_t **merge, int mode,
long i1, long chg1, long i2, long chg2)
{
xdmerge_t *m = *merge;
- if (m && mode == m->mode &&
- (i1 == m->i1 + m->chg1 || i2 == m->i2 + m->chg2)) {
+ if (m && (i1 <= m->i1 + m->chg1 || i2 <= m->i2 + m->chg2)) {
+ if (mode != m->mode)
+ m->mode = 0;
m->chg1 = i1 + chg1 - m->i1;
m->chg2 = i2 + chg2 - m->i2;
} else {
@@ -313,22 +314,10 @@ static int xdl_do_merge(xdfenv_t *xe1, xdchange_t *xscr1, const char *name1,
i1 = xscr1->i1 + xscr1->chg1;
i2 = xscr2->i1 + xscr2->chg1;
- if (i1 > i2) {
- xscr1->chg1 -= i1 - i2;
- xscr1->i1 = i2;
- xscr1->i2 += xscr1->chg2;
- xscr1->chg2 = 0;
+ if (i1 >= i2)
xscr2 = xscr2->next;
- } else if (i2 > i1) {
- xscr2->chg1 -= i2 - i1;
- xscr2->i1 = i1;
- xscr2->i2 += xscr2->chg2;
- xscr2->chg2 = 0;
- xscr1 = xscr1->next;
- } else {
+ if (i2 >= i1)
xscr1 = xscr1->next;
- xscr2 = xscr2->next;
- }
}
while (xscr1) {
if (!changes)
--
1.4.4.1.g394ac-dirty
^ permalink raw reply related
* Re: [PATCH] gitweb: Better symbolic link support in "tree" view
From: Jakub Narebski @ 2006-12-05 21:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr6vfkv3i.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> In "tree" view (git_print_tree_entry subroutine), add for symbolic
>> links after file name " -> link_target", a la "ls -l". Use
>> git_get_link_target_html to escape target name and make it into
>> hyperlink if possible.
>
> I think " -> link_target" is fine, but I do not know if it is
> useful (while I do not think it is wrong) to make the value that
> would have been returned from readlink() into an href, even when
> it points at something inside the same revision.
I have added this bit (making symbolic link target symlink) because
otherwise there is no way, besides hand-munging the URL, to go to the
link target.
From the command line, tools usually follow symlinks. In gitweb, "blob"
view (and "blob_plain" view) show symbolic link contents... not that
I'm for changing this, mind you.
--
Jakub Narebski
^ permalink raw reply
* Re: [PATCH 1/3] Document some current bugs and add to the TODO list.
From: Yann Dirson @ 2006-12-05 22:02 UTC (permalink / raw)
To: Catalin Marinas; +Cc: GIT list
In-Reply-To: <b0943d9e0612050930t187e65c4g6a3c44ea1fefc940@mail.gmail.com>
On Tue, Dec 05, 2006 at 05:30:56PM +0000, Catalin Marinas wrote:
> On 30/11/06, Yann Dirson <ydirson@altern.org> wrote:
> >+- numeric shortcuts for naming patches near top (eg. +1, -2)
>
> We currently have the -n option for push and pop that accepts number.
> Because of python, you can also, for example, push to the last but one
> with "push -n -1" (similar for pop). Do you mean shortcuts for the
> "goto" command?
I rather meant shortcuts for "show", "fold --pick", and possibly a
handful of others.
While we're talking about shortcuts for goto, one that I regularly miss
would be something like "goto BACK", to allow for short excursions and
quickly going back without having to worry on which exact patch I was
before. "refresh --patch" will make this less essential, but still
possibly useful.
> >+- refuse to "stg init" a branch known as remote (through .git/remotes/,
> >+ .git/branches/ or any other info)
>
> I think it is up to the user not to do this.
It may not be obvious to a new user, so I'd think it would be useful to
guard against things we know should not be done.
"git checkout" being probably used as plumbing in several places should
probably not be taught to refuse switching to remote branches, so I'd
think porcelains should take care of this.
> You would first need to check out such a branch anyway.
Sure. Especially, the following should probably fail :)
|stgit$ stg branch origin
|Switching to branch "origin"... done
Maybe it could be made to accept only to change to stgit-managed
branches ?
After all, if we're switching to a non-stgit branch, we're probably
going to use another set of tools anyway, so we can probably tell the
user to use git-checkout or cg-switch instead.
> >+- cannot use "stg refresh file" after "cg-rm file"
>
> It seems to work for me. Can you send some log messages?
I should have done that first, I cannot reproduce it any more.
> >+- "stg goto $(stg top)" fails with unhandled exception
>
> It works for me. What StGIT version do you use?
I got that error on 0.11 - and just checked that
9b63cf56576bf219d26f490f3c011e937a5f7129 fixes exactly this problem
already. Sorry, I should have checked on master first.
> >+- at least "commit is not robust wrt out-of-diskspace condition:
> >+|deps$ stg commit
> >+|error: git-checkout-index: unable to write file MANIFEST
> >+|error: git-checkout-index: unable to write file META.yml
> >+|error: git-checkout-index: unable to write file Makefile.PL
> >+|error: git-checkout-index: unable to write file doc/README.dbk.xml
> >+|error: git-checkout-index: unable to write file graph-includes
> >+|error: git-checkout-index: unable to write file
> >lib/graphincludes/params.pm
> >+|fatal: unable to write new index file
> >+|stg commit: git-read-tree failed (local changes maybe?)
> >+|Committing 4 patches...
> >+(luckily nothing was really committed)
>
> But that's the correct behaviour, not to commit anything.
Right.
> StGIT cannot know
> how much space is needed by GIT to check this beforehand. It simply
> exits when a GIT command failed.
What I had in mind, is that when something fails midway, if we just exit
we may end up in an inconsistent state. I have not taken the time to
check about that, that's why I wanted it to appear in the TODO file.
Again, it was quite poorly worded, to say the least.
Best regards,
--
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: sf @ 2006-12-05 22:07 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0612042053080.20138@iabervon.org>
Daniel Barkalow wrote:
> On Sat, 2 Dec 2006, Linus Torvalds wrote:
>
>> So that's where I come from. And maybe I'm totally wrong. I'd like to hear
>> what people who actually _use_ submodules think.
>
> I think you'd rather hear from people who _would_ use submodules; I've
> worked on a number of projects that would have benefitted from that
> general functionality, but nobody trusted the implementation enough to
> actually use it.
>
> At my work, we're doing a bunch of stuff with microcontrollers. We've got
> about a dozen different boards with microcontrollers, and each of them has
> different firmware. We also have a bunch of code that can go on any of the
> boards.
>
> The way things are organized currently is that each board has its own
> project, and there's a "common-micro" project with the common code. This
> sort of works, but it means that when you change things in common-micro,
> you never know what effect this will have on boards other than the one
> you're actually working on. What I'd like to have is that each project has
> a "common-micro" subdirectory, and changes to each of these can be merged
> into each other, but that doesn't happen automaticly, and each board's
> revisions include the common-micro revision they were created with.
Our setup and requirements at work are exactly the same: We have a few
main projects that are developed independently and we have one "helper"
project for code that is general enough to be reused. So work on the
helper project is only done while working on one of the main projects.
When we switch to another main project we integrate the changes to the
"helper" project.
That's the theory, at least.
Regards
Stephan
^ permalink raw reply
* Re: [PATCH] xdl_merge(): fix and simplify conflict handling
From: Junio C Hamano @ 2006-12-05 22:10 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Linus Torvalds, Ramsay Jones
In-Reply-To: <Pine.LNX.4.63.0612052209030.28348@wbgn013.biozentrum.uni-wuerzburg.de>
Thanks.
Looking at some other cases after applying your patch, I noticed
that I really like one thing that your version does over what
RCS merge does.
With RCS merge, a run of lines that are modified the same way in
both branches appear twice, like this:
<<< orig
alpha
bravo
charlie
...
x-ray
yankee
zulu
===
alpha
bravo
charlie
...
x-ray
yankee
zebra
>>> new
The common part at the beginning (or at the end for that
matter) can be hoisted outside, to produce:
alpha
bravo
charlie
...
x-ray
yankee
<<< orig
zulu
===
zebra
>>> new
and your version seems to get this right.
When I had to deal with this kind of conflicts, I ended up
splitting the buffer in two, and ran M-x compare-windows to find
the true differences between the choices. It was frustrating.
(I admit a big reason is I do not normally work in X environment
and do not tend to use xdiff -U or Kompare).
This is especially noticeable when recreating diff-delta.c merge
conflict in commit b485db98. It's fun to see this large hunk
reduced down to only two lines ;-).
<<<<<<< HEAD/diff-delta.c
/*
* Determine a limit on the number of entries in the same hash
* bucket. This guard us against patological data sets causing
* really bad hash distribution with most entries in the same hash
* bucket that would bring us to O(m*n) computing costs (m and n
* corresponding to reference and target buffer sizes).
*
* The more the target buffer is large, the more it is important to
* have small entry lists for each hash buckets. With such a limit
* the cost is bounded to something more like O(m+n).
*/
hlimit = (1 << 26) / trg_bufsize;
if (hlimit < 16)
hlimit = 16;
/*
* Now make sure none of the hash buckets has more entries than
* we're willing to test. Otherwise we short-circuit the entry
* list uniformly to still preserve a good repartition across
* the reference buffer.
*/
for (i = 0; i < hsize; i++) {
if (hash_count[i] < hlimit)
continue;
entry = hash[i];
do {
struct index *keep = entry;
int skip = hash_count[i] / hlimit / 2;
do {
entry = entry->next;
} while(--skip && entry);
keep->next = entry;
} while(entry);
}
free(hash_count);
return hash;
=======
/*
* Determine a limit on the number of entries in the same hash
* bucket. This guard us against patological data sets causing
* really bad hash distribution with most entries in the same hash
* bucket that would bring us to O(m*n) computing costs (m and n
* corresponding to reference and target buffer sizes).
*
* The more the target buffer is large, the more it is important to
* have small entry lists for each hash buckets. With such a limit
* the cost is bounded to something more like O(m+n).
*/
hlimit = (1 << 26) / trg_bufsize;
if (hlimit < 16)
hlimit = 16;
/*
* Now make sure none of the hash buckets has more entries than
* we're willing to test. Otherwise we short-circuit the entry
* list uniformly to still preserve a good repartition across
* the reference buffer.
*/
for (i = 0; i < hsize; i++) {
if (hash_count[i] < hlimit)
continue;
entry = hash[i];
do {
struct index *keep = entry;
int skip = hash_count[i] / hlimit / 2;
do {
entry = entry->next;
} while(--skip && entry);
keep->next = entry;
} while(entry);
}
free(hash_count);
return hash-1;
>>>>>>> 38fd0721d0a2a1a723bc28fc0817e3571987b1ef/diff-delta.c
^ permalink raw reply
* Re: [PATCH] xdl_merge(): fix and simplify conflict handling
From: Johannes Schindelin @ 2006-12-05 22:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Linus Torvalds, Ramsay Jones
In-Reply-To: <7vvekqf0yh.fsf@assigned-by-dhcp.cox.net>
Hi,
On Tue, 5 Dec 2006, Junio C Hamano wrote:
> Looking at some other cases after applying your patch, I noticed that I
> really like one thing that your version does over what RCS merge does.
Gee, thanks!
Actually, this was what I intended to do first when somebody submitted a
builtin merge: Be clever about what is a conflict and what not.
Speaking about a builtin merge: I like the fact that git-apply also works
outside of git repositories. It makes life easier to have a sane patcher
around.
Now, I'd like the same with git-diff, and an RCS merge replacement... Of
course, what with all those porcelainish commands we should not add new
commands, but enhance existing ones. Any ideas which ones?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] xdl_merge(): fix and simplify conflict handling
From: Jakub Narebski @ 2006-12-05 22:27 UTC (permalink / raw)
To: git
In-Reply-To: <7vvekqf0yh.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Looking at some other cases after applying your patch, I noticed
> that I really like one thing that your version does over what
> RCS merge does.
Is it with "try harder" option?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] gitweb: Better symbolic link support in "tree" view
From: Junio C Hamano @ 2006-12-05 22:34 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200612052227.56770.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Junio C Hamano wrote:
>> ...
>> I think " -> link_target" is fine, but I do not know if it is
>> useful (while I do not think it is wrong) to make the value that
>> would have been returned from readlink() into an href, even when
>> it points at something inside the same revision.
>
> I have added this bit (making symbolic link target symlink) because
> otherwise there is no way, besides hand-munging the URL, to go to the
> link target.
I can read what you wrote it does.
For one thing, the user is tracking the symbolic link itself,
not the contents of the file or directory the link points at.
For that "tracked symlink", where it points at is the important
content, not what the file that is pointed at happens to contain
in the same revision.
If you have to open an extra object while drawing the list, I do
not think it is worth doing it.
In order to show " -> link_target", you have to read the
contents of the blob. I think that overhead to read one extra
blob is probably an acceptable tradeoff for convenience.
But if you want to make it a link into the same tree, you would
need to check if link_target path exists and if it is a blob or
tree to produce an appropriate tree_view/blob_view link (I
haven't read your code but that is the natural thing to do).
That would involve in reading a few more tree objects (depending
on how deep the target is in the tree), and I do not think it is
worth doing it while drawing a list. After you prepared dozens
of such links, the user would click at most one of them and
leaves the page; your cycles to draw those unclicked links were
wasted.
If you wanted to do this, a better way would be to have a new
view that takes a commit/tree object and a path from the top of
the repository, and shows either "no such path in that tree" or
"here is the view for that object, by the way it was a blob."
page. Then your list drawing would still need to open each
symlink blob to show " -> link_target", and need to check if it
goes outside the repository (I would assume you are handling
relative links as well), but you do not need to do expensive
ls-tree step one per symlink on the page. The href attr of the
A element " -> link_target" would point at that "universal
object view" with the link_target pathname (that is, the blob
contents) and the commit/tree object name (h or hb I do not know
which) and you will spend cycles to run ls-tree only when the
user actually asks to follow that link.
In other words, I think trying to be lazy is extremely important
while drawing a big list.
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Johannes Schindelin @ 2006-12-05 22:42 UTC (permalink / raw)
To: Han-Wen Nienhuys; +Cc: git
In-Reply-To: <4566E512.4010405@xs4all.nl>
Hi,
On Fri, 24 Nov 2006, Han-Wen Nienhuys wrote:
> The recently posted patch documenting is an improvement, but why not
> add an option so you can do
>
> --format 'committer %c\nauthor %a\n'
>
> this catches all combinations, and is easier for scripting.
Yes, it would be easier for scripting, and it would probably be relatively
easy, what with the addition of interpolate.[ch] to git. However, it is
work, and I am lazy.
What information would you like, anyway? IOW can you provide me with a
list like this:
%c committer
%a author
%d committer_date
...
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] xdl_merge(): fix and simplify conflict handling
From: Johannes Schindelin @ 2006-12-05 22:27 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <el4rko$aqe$1@sea.gmane.org>
Hi,
On Tue, 5 Dec 2006, Jakub Narebski wrote:
> Junio C Hamano wrote:
>
> > Looking at some other cases after applying your patch, I noticed
> > that I really like one thing that your version does over what
> > RCS merge does.
>
> Is it with "try harder" option?
Yes, it uses the XDL_MERGE_ZEALOUS option.
Ciao,
Dscho
^ permalink raw reply
* Re: Handling of branches in stgit
From: Yann Dirson @ 2006-12-05 22:51 UTC (permalink / raw)
To: Catalin Marinas; +Cc: GIT list
In-Reply-To: <20061201221941.GA32337@nan92-1-81-57-214-146.fbx.proxad.net>
On Fri, Dec 01, 2006 at 11:19:41PM +0100, Yann Dirson wrote:
> > > annoying [ISSUE 1]. Hence this work of mine: being able to store
> > > this info in .git/patches/<stack>/parent (my initial implementation)
> > > was sufficient in theory.
> >
> > I would leave this to GIT and its configuration files. Do you see any
> > problems with this approach?
>
> I'd rather consider it a stgit issue: git itself does no have to know
> which of the various heads descending from our stack base is to be
> "prefered" by our stack. Where to store it is anothe issue (see below).
>
>
> > I plan to merge the stgit config with the git one (and have a [stgit]
> > section) so that it is more maintainable.
>
> Sure, let's take advantage of git-repo-config !
> My latest 1/3 patch could then be seen as a 1st step towards an
> abstraction of stgit object configuration, which could ease the transition
Indeed most of the current attributes of a stack (except maybe for the
description, which can hardly be seen as a config option) are quite
volatile, and thus unsuited for repo-config.
OTOH, as you said parent information would find easily its place there.
> > On 30/11/06, Yann Dirson <ydirson@altern.org> wrote:
> > >I have started to work on recording parent information for stgit
> > >branches, so we don't need to give the same info on every "git pull".
> >
> > Isn't this what the branch.<name>.remote configuration option is for?
> > I think we should leave GIT handle this and StGIT only invoke "git
> > pull" without any arguments.
>
> This is one part of the problem (and I admit I have missed this config option),
> the other one being having stgit pull the correct branch, unstead of
> (implicitely) having git-pull using the 1st one in the remotes file.
I would also think that what really belongs to that config item would
be the declaration of which remote our parent branch should use to be
updated (ie. no need to duplicate the info in all the stgit stacks
forked off the same parent).
However it looks like this config option is not currently used unless
the branch to be git-fetched is the curent one, which is quite
annoying - we would need to get that setting ourselves to pass it to
git-fetch.
What's not clear to me is how to deal with cogito branches (maybe
check for the existence of .git/branches/<name> and then "git fetch
<name>" ?), and with local branches (how are we supposed to derive
that a branch is not a remote one ? Should GIT add a
branch.<name>.remote or "." for locally-created branches ?).
We would also still need a config item to tell which parent branch we
should use, in order to know which branch.<name>.remote to extract,
and which branch to fast-forward our base onto.
Best regards,
--
^ permalink raw reply
* Re: [PATCH] xdl_merge(): fix and simplify conflict handling
From: Junio C Hamano @ 2006-12-05 22:54 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0612052320320.28348@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Speaking about a builtin merge: I like the fact that git-apply also works
> outside of git repositories. It makes life easier to have a sane patcher
> around.
Well, git-apply is designed as a better "patch", so it is
natural that it works in a non-git directory [*1*].
I am not sure what you mean by a builtin merge that works
outside the context of git. Do you mean a pure RCS merge
replacement that takes three files and spits out the result in
one of them? If so that would probably deserve to be a separate
command, because I do not think of a use for such a thing inside
git. We've done merge-recursive.c already so it would not need
an external 'merge'. If somebody is so inclined to to do the
"merge-resolve" strategy, I think the right way is to make a
single program that does what git-merge-index and merge-one-file
does without fork nor exec, so it would not need an external
'merge' either.
> Now, I'd like the same with git-diff, and an RCS merge replacement...
Yes, back when I was actively hacking git-diff, I dreamt about a
variant that takes two or more (non-git managed) directories and
does an equivalent of diff-tree with -M/-C/.../-c/--cc. It
would be cool and useful.
I understand your aversion to new commands, but I do not think
you can avoid it if what you mean is an RCS merge replacement.
The diff that works on "two or more directories without anything
git" could be just a new option to "git diff", though.
But I am not going to do it myself; it's usually a lot faster
for me to just do "git init-db; git add . " on an extracted
tarball.
[Footnote]
*1* ... and that is one of the reasons why it does not even try
to read the index unless it is told to do so.
And we should not make it "detect we are in git repository" and
default to --index either. Often running without --index is
useful inside a git repository. I would say roughly 50% of the
time I use the command with --index and the rest without, so
"more often" argument unfortunately does not apply to "apply".
I wish it were "2% without --index, 98% with --index". Then we
could easily say "add '--no-index if you do not want to".
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Junio C Hamano @ 2006-12-05 22:58 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Han-Wen Nienhuys
In-Reply-To: <Pine.LNX.4.63.0612052340260.28348@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Fri, 24 Nov 2006, Han-Wen Nienhuys wrote:
>
>> The recently posted patch documenting is an improvement, but why not
>> add an option so you can do
>>
>> --format 'committer %c\nauthor %a\n'
>>
>> this catches all combinations, and is easier for scripting.
>
> Yes, it would be easier for scripting, and it would probably be relatively
> easy, what with the addition of interpolate.[ch] to git. However, it is
> work, and I am lazy.
Lazy is good when the details should not matter. If some people
are scripting, they are fully capable of reading raw or fuller.
^ permalink raw reply
* Re: [PATCH] git-explain
From: Martin Langhoff @ 2006-12-05 23:00 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <el3ibq$9kn$2@sea.gmane.org>
On 12/5/06, Jakub Narebski <jnareb@gmail.com> wrote:
> Junio C Hamano wrote:
>
> > [PATCH] git-explain
> >
> > This patch adds "git-explain" script that notices various clues
> > other commands can leave the working tree and repository in and
> > intended to guide the end user out of the confused mess.
>
> I like it, although I think that it explains a bit too little
I like what it does too... but why not as part of git-status?
cheers,
^ permalink raw reply
* Re: [PATCH] gitweb: Better symbolic link support in "tree" view
From: Jakub Narebski @ 2006-12-05 23:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk616ezu5.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> Junio C Hamano wrote:
>>> ...
>>> I think " -> link_target" is fine, but I do not know if it is
>>> useful (while I do not think it is wrong) to make the value that
>>> would have been returned from readlink() into an href, even when
>>> it points at something inside the same revision.
>>
>> I have added this bit (making symbolic link target symlink) because
>> otherwise there is no way, besides hand-munging the URL, to go to the
>> link target.
>
> I can read what you wrote it does.
>
> For one thing, the user is tracking the symbolic link itself,
> not the contents of the file or directory the link points at.
> For that "tracked symlink", where it points at is the important
> content, not what the file that is pointed at happens to contain
> in the same revision.
>
> If you have to open an extra object while drawing the list, I do
> not think it is worth doing it.
>
> In order to show " -> link_target", you have to read the
> contents of the blob. I think that overhead to read one extra
> blob is probably an acceptable tradeoff for convenience.
Especially that it is done _only_ if there exist symbolic link
entry in a tree.
> But if you want to make it a link into the same tree, you would
> need to check if link_target path exists and if it is a blob or
> tree to produce an appropriate tree_view/blob_view link (I
> haven't read your code but that is the natural thing to do).
>
> That would involve in reading a few more tree objects (depending
> on how deep the target is in the tree), and I do not think it is
> worth doing it while drawing a list. After you prepared dozens
> of such links, the user would click at most one of them and
> leaves the page; your cycles to draw those unclicked links were
> wasted.
Actually this requires only one call to git-ls-tree
$ git ls-tree $hash_base -- $target_path
Internally this mean reading a few more tree objects, but in gitweb
the cost of fork is what (I think) dominates.
> If you wanted to do this, a better way would be to have a new
> view that takes a commit/tree object and a path from the top of
> the repository, and shows either "no such path in that tree" or
> "here is the view for that object, by the way it was a blob."
> page. Then your list drawing would still need to open each
> symlink blob to show " -> link_target", and need to check if it
> goes outside the repository (I would assume you are handling
> relative links as well),
I handle _only_ relative links. There is no way to treat absolute links
leading within repository (well, there is, but absoulte links depends
on position of repository in the filesystem, and that is usually bad
idea... unless absolute link is not to file within repository). The
link is "normalized" to path from the top of the tree/top of repository
tree (dealing with /./, /../, and // in the way).
> but you do not need to do expensive
> ls-tree step one per symlink on the page. The href attr of the
> A element " -> link_target" would point at that "universal
> object view" with the link_target pathname (that is, the blob
> contents) and the commit/tree object name (h or hb I do not know
> which) and you will spend cycles to run ls-tree only when the
> user actually asks to follow that link.
>
> In other words, I think trying to be lazy is extremely important
> while drawing a big list.
Well, that is certainly another solution. I'm not sure if distinction
between checking if link target exists (and getting target type while
at it) and providing link to perhaps "no such patch in that tree" page
is worth %feature... well, I guess it is not.
I'll split the patch into two: first to read link target and show it in
"tree" view _without_ hyperlink, and later perhaps either your or mine
solution (most probably yours), depending on feedback.
--
Jakub Narebski
^ permalink raw reply
* Re: [PATCH] git-explain
From: Junio C Hamano @ 2006-12-05 23:07 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90612051500w44438f70y3c7d1c99998d16bb@mail.gmail.com>
"Martin Langhoff" <martin.langhoff@gmail.com> writes:
> On 12/5/06, Jakub Narebski <jnareb@gmail.com> wrote:
>> Junio C Hamano wrote:
>>
>> > [PATCH] git-explain
>> >
>> > This patch adds "git-explain" script that notices various clues
>> > other commands can leave the working tree and repository in and
>> > intended to guide the end user out of the confused mess.
>>
>> I like it, although I think that it explains a bit too little
>
> I like what it does too... but why not as part of git-status?
The biggest reason was that it is a demonstration of concepts,
not replacement of anything. Maybe "git status" can be replaced
with something like that if people worked on it enough.
The current use of "git status" inside "git commit" needs to be
revamped if we pursue this further, though. Because one of the
points the "what state is this repository in" check "explain"
does is to define what operations are sensible in each state,
and most likely in many state it would not make _any_ sense to
run "git commit" (say, in the middle of "bisect").
^ permalink raw reply
* Re: [PATCH] git-explain
From: Johannes Schindelin @ 2006-12-05 23:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Martin Langhoff, git
In-Reply-To: <7vslfudjsa.fsf@assigned-by-dhcp.cox.net>
Hi,
On Tue, 5 Dec 2006, Junio C Hamano wrote:
> "Martin Langhoff" <martin.langhoff@gmail.com> writes:
>
> > I like what it does too... but why not as part of git-status?
>
> The biggest reason was that it is a demonstration of concepts,
> not replacement of anything. Maybe "git status" can be replaced
> with something like that if people worked on it enough.
Okay, so what do people need? This is evidently a question for people who
are not intimately familiar with the core of Git. So, where are you
newbies when we need you? Speak up!
Surely, you hit a wall on the road, where you really wanted to ask "git
wtf"?
> The current use of "git status" inside "git commit" needs to be revamped
> if we pursue this further, though. Because one of the points the "what
> state is this repository in" check "explain" does is to define what
> operations are sensible in each state, and most likely in many state it
> would not make _any_ sense to run "git commit" (say, in the middle of
> "bisect").
That is right, but it is only a matter of having a command line switch to
suppress what you do not need for the commit message. After all, "status"
really should tell you about the status of the working directory. The fact
that we have the _same_ script for "commit" and "status" is no excuse!
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-explain
From: Junio C Hamano @ 2006-12-05 23:57 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0612060033540.28348@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Tue, 5 Dec 2006, Junio C Hamano wrote:
>...
>> The current use of "git status" inside "git commit" needs to be revamped
>> if we pursue this further, though. Because one of the points the "what
>> state is this repository in" check "explain" does is to define what
>> operations are sensible in each state, and most likely in many state it
>> would not make _any_ sense to run "git commit" (say, in the middle of
>> "bisect").
>
> That is right, but it is only a matter of having a command line switch to
> suppress what you do not need for the commit message. After all, "status"
> really should tell you about the status of the working directory. The fact
> that we have the _same_ script for "commit" and "status" is no excuse!
Sure. The way I envisioned it was that we would have a moral
equivalent of current git-status output for explanation of the
base state.
I originally wanted to do "git oops" which would have been a
universal "undo" command, and "explain" was only the first
smaller step toward that goal. But the more I think about it, I
feel that "undo" is less important.
^ permalink raw reply
* Re: [PATCH] git-explain
From: Carl Worth @ 2006-12-06 0:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vu009dhgz.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 880 bytes --]
On Tue, 05 Dec 2006 15:57:00 -0800, Junio C Hamano wrote:
> I originally wanted to do "git oops" which would have been a
> universal "undo" command, and "explain" was only the first
> smaller step toward that goal. But the more I think about it, I
> feel that "undo" is less important.
I like the idea of "git status" explaining what operations are "in
progress" and what the user might want to do next to complete the
operation.
As for the desire for "undo", it probably makes sense to just keep
focusing on making "git reset" a nice, safe way to undo any sort of
"in progress" operation. The recent cleanup patches are in line with
this.
One thing that conflicts with that goal a bit is that git-reset is
also used to move the current branch arbitrarily in the commit DAG,
and also (with --hard) to discard local commits. Those are definitely
less "safe" operations.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: For all you darcs lovers: git-hunk-commit
From: Han-Wen Nienhuys @ 2006-12-06 0:19 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0612051936480.28348@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin escreveu:
> I was inspired by Han-Wen. This script allows you to commit selected hunks
Wow!
> In darcs mode, all hunks are presented one by one, and you are asked if
> you want to commit this or not. If you make a mistake: ^C and back to
> start. I do not really know darcs, so this might not be how it works -- I
> did not find any good documentation how a "darcs record" looks like.
This is the interactive interface for commits in Darcs. It uses the
same interface for pushing and pulling, where I mostly use y/n/a/d but
sometimes the other letters too.
****
Shall I record this change? (1/?) [ynWsfqadjkc], or ? for help: ?
How to use record...
y: record this patch
n: don't record it
w: wait and decide later, defaulting to no
s: don't record the rest of the changes to this file
f: record the rest of the changes to this file
d: record selected patches, skipping all the remaining patches
a: record all the remaining patches
q: cancel record
j: skip to next patch
k: back up to previous patch
c: calculate number of patches
h or ?: show this help
<Space>: accept the current default (which is capitalized)
****
If you want to get a feel for it, grab darcs and run
darcs init
echo hello > hello
darcs add
darcs record
For a really neat implementation of per-hunk commits, try running
darcsum in Emacs
> done < <(git ls-files --modified -z)
> done < <(git diff "$filename")
> done < <(echo ${hunks[$index]} | tr , '\n')
am I running the wrong bash? it barf on this. Don't you mean $(echo ... )
Frankly, I am amazed that people write things in bash at all--I vowed never
to write bash again a couple of years ago. If you start doing arrays and
counting, wouldn't a more high-level language be suitable?
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Re: [PATCH] git-explain
From: Johannes Schindelin @ 2006-12-06 0:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vu009dhgz.fsf@assigned-by-dhcp.cox.net>
Hi,
On Tue, 5 Dec 2006, Junio C Hamano wrote:
> But the more I think about it, I feel that "undo" is less important.
Me, too. I was really astonished that people said -- after quite some
explanations -- "wow, you mean I did not lose any work?"
That's the nice thing about git: it is really hard to lose any objects.
Unless you explicitely issue a "git prune", you can resurrect whatever was
your state.
In this spirit, maybe it is time to enable reflog per default?
Ciao,
Dscho
^ permalink raw reply
* Re: For all you darcs lovers: git-hunk-commit
From: Johannes Schindelin @ 2006-12-06 0:36 UTC (permalink / raw)
To: Han-Wen Nienhuys; +Cc: git
In-Reply-To: <45760CA3.9060003@xs4all.nl>
Hi,
On Wed, 6 Dec 2006, Han-Wen Nienhuys wrote:
> This is the interactive interface for commits in Darcs. It uses the
> same interface for pushing and pulling, where I mostly use y/n/a/d but
> sometimes the other letters too.
>
>
> ****
> Shall I record this change? (1/?) [ynWsfqadjkc], or ? for help: ?
> How to use record...
> y: record this patch
> n: don't record it
> w: wait and decide later, defaulting to no
>
> s: don't record the rest of the changes to this file
> f: record the rest of the changes to this file
>
> d: record selected patches, skipping all the remaining patches
> a: record all the remaining patches
> q: cancel record
>
> j: skip to next patch
> k: back up to previous patch
> c: calculate number of patches
> h or ?: show this help
>
> <Space>: accept the current default (which is capitalized)
> ****
All but "y" and "n" are unsupported in hunk-commit.bash... Do you use all
of these?
> If you want to get a feel for it, grab darcs and run
I already grabbed darcs a long time ago. And run, I did.
> > done < <(git ls-files --modified -z)
>
> > done < <(git diff "$filename")
>
> > done < <(echo ${hunks[$index]} | tr , '\n')
>
> am I running the wrong bash? it barf on this. Don't you mean $(echo ... )
I hoped that I did not use a too new bash. Unfortunately, I seem to have
been wrong. These constructs redirect the output of the command as input
to the while loop, because
bla | while ...; do blub; done
opens a subshell, so that all changes done in "blub" are lost as soon as
the while loop is finished.
> Frankly, I am amazed that people write things in bash at all--I vowed
> never to write bash again a couple of years ago. If you start doing
> arrays and counting, wouldn't a more high-level language be suitable?
Me, being one of the loudest proponents of C builtins on this list, I
agree fully.
But in this case, bash was faster to script and debug, and unless people
speak up, saying "I want that feature badly!", I do not plan to do
anything with it.
Ciao,
Dscho
^ permalink raw reply
* git newbie problems
From: Graham Percival @ 2006-12-06 0:41 UTC (permalink / raw)
To: git
In-Reply-To: <4574BF70.8070100@lilypond.org>
Greetings,
I'm posting these problems at Han-Wen and Dscho's insistence. I'm the
documentation editor for GNU/LilyPond, so I'm reluctant to criticize
other project's documentation unless I spend an hour or more seriously
reading it. I'm quite willing to admit that I never seriously tried to
read the docs on the overall theory of git (branches, repo, etc); I just
flailed around looking for magic commands to make things work. By "make
things work", I mean imitating my work style with cvs:
cvs co blah blah (which I simply copy and paste from savannah)
while (true) {
cvs update // get changes that happened overnight
vi foo/bar/baz.txt // or whatever editing commands you do
make; make web // or whatever testing commands you do
cvs update // get latest changes to prepare for
// uploading my changes.
cvs ci foo/bar/baz.txt // upload changes
}
Once or twice a year I'll do "cvs diff" or "cvs add", but all I really
want are the above commands. I figured that this should be really easy
to do, so I kept on skimming through the docs, trying to find the
equivalent of these really easy commands. (note that I was reading the
"tutorial introduction to git")
I should add that I've received help on the lilypond-devel list; I'm
posting this in case it helps future development for git docs, not
because I need more help to use git.
This case was particularly difficult because the very first time I tried
to commit... err... push... err... "make my doc changes available to
everybody else" (whatever the right term is), there was this merge problem.
MERGE PROBLEM
Two people (me and another person) edited the same line on
Documentation/user/advanced.itely at the same time. (note that this
file has existed for over a year; it's not a new file) When I tried to
get the most recent changes, I'm greeted with this:
...
Trying really trivial in-index merge...
Documentation/user/advanced-notation.itely: needs merge
fatal: you need to resolve your current index first
Nope.
Merging HEAD with c21d3f3e1c77722e50d994763442e6f994b03ac2
Merging:
038b7fc Misc small updates (trying to make git work).
c21d3f3 Merge branch 'master' of
ssh+git://hanwen@git.sv.gnu.org/srv/git/lilypond
found 1 common ancestor(s):
84219bb don't have input/templates/ any longer.
fatal: Entry '.gitignore' would be overwritten by merge. Cannot merge.
No merge strategy handled the merge.
As a git newbie, I'm quite confused. OK, there's no merge strategy...
so what do I do now? With cvs, the changes would be dumped into the
file. I look at the file, found the conflict, and tried it again. I
got the same error message, and then it occurred to me that although I
changed the files in my ~/usr/src/lilypond, git might be storing these
files somewhere else. So I tried
$ git commit Documentation/user/advanced-notation.itely
Cannot do a partial commit during a merge.
You might have meant to say 'git commit -i paths...', perhaps?
... eh? I'm trying to fix this so that you _can_ merge! Regardless,
when I tried to update again, I get
$ git pull gnu master
...
Trying really trivial in-index merge...
fatal: Entry '.gitignore' would be overwritten by merge. Cannot merge.
Nope.
Merging HEAD with c21d3f3e1c77722e50d994763442e6f994b03ac2
Merging:
038b7fc Misc small updates (trying to make git work).
c21d3f3 Merge branch 'master' of
ssh+git://hanwen@git.sv.gnu.org/srv/git/lilypond
found 1 common ancestor(s):
84219bb don't have input/templates/ any longer.
fatal: Entry '.gitignore' would be overwritten by merge. Cannot merge.
No merge strategy handled the merge.
Now I'm totally confused, because I definitely haven't touched .gitignore.
SUGGESTIONS
The "tutorial introduction to git" looks like a nice document, but it
assumes that you are in control of the project. For users who aren't in
control (ie me) this is a problem, because it starts me skimming.
"Importing a project"... nah, that's not me. "Merging branches"... I
don't care; I'm going to shove everything into the main branch. "Using
git for collaboration"... hmm, maybe this is the stuff I need to read.
But by this point, I've already skimmed through five screens of info, so
I'm not reading very carefully.
It would be nice to have an accompanying "tutorial introduction to
contributing with git" for users (like me) who are not in control of a
project.
Finally, it would be really nice if there was some mention of "resolving
merge problems" in the tutorial (both in the current one and any new docs).
Cheers,
- Graham Percival
^ permalink raw reply
* Re: [RFC] Two conceptually distinct commit commands
From: Junio C Hamano @ 2006-12-06 1:13 UTC (permalink / raw)
To: Carl Worth; +Cc: git
In-Reply-To: <87d56z32e1.wl%cworth@cworth.org>
Carl Worth <cworth@cworth.org> writes:
> ... The case I would use it for is fairly common,
> (and something that I think will speak to Junio who often brings
> up a similar scenario).
>
> Here's where I would like this functionality:
>
> I receive a patch while I'm in the middle of doing other work,
> (but with a clean index compared to HEAD, which is what I've
> usually). The patch looks good, so I want to commit it right
> away, but I do want to separate it into two or more pieces,
> (commonly this is because I want to separate the "add a test
> case demonstrating a bug" part from the "fix the bug"
> part).
(This is offtopic)
I often faced situations like that during git.git history. One
patch to expose the bug in the existing code, and another to fix
it. And there are three ways to make that commit.
(1) one commit exposes, then another fixes.
(2) one commit fixes, then another verifies the bug is no more.
(3) one commit to include both.
In my experience, (1) is only useful during the time I am coming
up with the fix (if I am fixing it myself) or during the time I
am reviewing and committing the fix (if I am applying somebody
else's patch). Committing in that order lets me validate the
brokenness after making the first commit, and then lets me feel
good by not seeing that problem after the second commit. But
this means I deliberately record a state that is known not to
pass the test, which means it is a problem for somebody else in
the future when the history needs to be bisected to hunt for an
unrelated bug. If the "test" is just an optional test in the
test suite, then it is easy to work around (the person who is
bisecting can ignore that bug by not running that particular
test), but if it is an assert somewhere deep inside the code,
ignoring it is not very easy, especially if the person who is
bisecting is not familiar with that part of the code.
What I recommend people to do these days is either (2) or (3),
but do so _after_ verifying the fix in the reverse order. The
criteria to choose between (2) or (3) is fairly simple: if the
"test" is easily separable (e.g. changes to a test script file
that does not overlap with the "fix" patch), roll both in one
commit. Then it would not later cause problems for bisection.
Enough of offtopic.
The sequence to split a patch in place would be (I'll speak in
the present tense and pretend Nico's "git add" does not exist
yet):
git apply
git update-index <files for the first batch>
git commit
git commit -a ;# the remainder
so you do not necessarily need a new "concept". It is
inconvenient that you need to deal with new files, but that is a
minor detail compared to a bigger problem I'll mention in the
next paragraph.
I think the problem with your thinking is that you still are
talking from "file boundary matters" point of view. The above
sequence is only useful if the patch to be split is separable
cleanly at the file boundary, in which case, I would (and I've
done so often) split the patch file in my editor and run two
independent "git apply + git commit" sequences. That way, I
could test each in isolation (perhaps with some dirty working
tree state if I do not stash them away and do reset --hard).
Anything more realistic and practically useful would require
splitting of the patch in semantic ways regardless of file
boundaries.
As I have already said (and you seemed to share the same
discipline), I do not like people committing anything
non-trivial that is not tested. The patch you received might
not have been tested by the submitter, but there is a chance
that it might have been ;-). But with the way you said you want
to make the commits in the message I am responding to, the first
commit would never have been tested by anybody in isolation, not
by the original submitter even if he tested the patch before
giving it to you, nor you -- your working tree had either none
of his patch or all of it, and never was in the state with only
the first batch.
So while at the theoretical level I understand what you would
want to achieve with the "single patch that should have been
sent as two patch series" example, from the practical point of
view I do not see much value in it (because "file boundary
matters" is a minority case that is not very interesting), and
from the discipline point of view I would rather not want to
have such a too-convenient way to commit things that were
different in nontrivial ways from what you had in your working
tree (if we use something like Darcs record to update
hunk-by-hunk).
> The old behavior is still available with the --include option, but
> nobody has ever come out in favor of that being a useful command,
That is a slight overstatement. When committing with paths
argument to conclude a merge, --include semantics is the only
variant that makes sense (--only semantics is so wrong that
there is a safety valve that catches it). Most of the time,
however, if I need to resolve and record a complicated merge, I
would either do "update-index" to clear the deck of the paths
that I already dealt with, and by the time I would type "git
commit", I have an index that has exactly what I want in the
merge commit. That makes --include a less often used form. If
a merge is small and easy to resolve at only a few paths, it
still is handy to say "git commit -i resolved-path.c". It does
not add anything to the semantics -- it is only a typesaver.
^ 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