* Re: VCS comparison table
From: Andreas Ericsson @ 2006-10-25 9:35 UTC (permalink / raw)
To: Matthew D. Fuller
Cc: Carl Worth, Aaron Bentley, Linus Torvalds, bazaar-ng, git,
Jakub Narebski
In-Reply-To: <20061021130111.GL75501@over-yonder.net>
Matthew D. Fuller wrote:
> On Fri, Oct 20, 2006 at 02:48:52PM -0700 I heard the voice of
> Carl Worth, and lo! it spake thus:
>
>> (since pull seems the only way to synch up without infinite new
>> merge commits being added back and forth).
>
> The infinite-merge-commits case doesn't happen in bzr-land because we
> generally don't merge other branches except when the branch owner says
> "Hey, I've got something for you to merge". If you were to setup a
> script to merge two branches back and forth until they were 'equal',
> yes, it'd churn away until you filled up your disk with the N bytes of
> metadata every new revision uses up.
>
This is new to me. At work, we merge our toy repositories back and forth
between devs only. There is no central repo at all. Does this mean that
each merge would add one extra commit per time the one I'm merging with
has merged with me?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-25 9:32 UTC (permalink / raw)
To: git; +Cc: bazaar-ng
In-Reply-To: <Pine.LNX.4.64N.0610250157470.3467@attu1.cs.washington.edu>
David Rientjes wrote:
> On Wed, 25 Oct 2006, Jeff King wrote:
>
>> I don't understand how converting shell scripts to C has any impact
>> whatsoever on the usage of git. The plumbing shell scripts didn't go
>> away; you can still call them and they behave identically.
>>
>> Is there some specific change in functionality that you're lamenting?
>>
>
> No, my criticism is against the added complexity which makes the
> modification of git increasingly difficult with every new release. It's a
> pretty limited use case of the entire package, I'm sure, but one of the
> major advantages that I saw in git early on was the ability to tailor it
> to your own personal needs very easily with some simple shell knowledge
> and enough C that was required at the time.
>
[...]
>> Is there something you used to do with git that you no longer can? Is
>> there a reason you can't ignore the newer commands?
>
> Functionality wise, no. But in terms of being able to _customize_ my
> version of git depending on how I want to use it, I've lost hope on the
> whole idea. It's a shame too because it appears as though the original
> vision was one of efficiency and simplicity. I would say that git-1.2.4
> is my package of preference with some slight tweaking in the branching
> department.
Ahah! So you miss the old script version of git commands, which you could
easily modify, tailoring it to your needs, isn't it? Well, if you don't mind
keeping your clone of git repository lying around somewhere, you can always
resurrect old shell version of some git command, e.g.
$ git cat-file -p v1.2.4:git-prune.sh > $(git --exec-path)/git-prune.sh
change its name and modify as you used to do.
Are there any old commands which stopped working?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: VCS comparison table
From: David Rientjes @ 2006-10-25 9:19 UTC (permalink / raw)
To: Jeff King; +Cc: Linus Torvalds, Lachlan Patrick, bazaar-ng, git
In-Reply-To: <20061025084810.GA26618@coredump.intra.peff.net>
On Wed, 25 Oct 2006, Jeff King wrote:
> I don't understand how converting shell scripts to C has any impact
> whatsoever on the usage of git. The plumbing shell scripts didn't go
> away; you can still call them and they behave identically.
>
> Is there some specific change in functionality that you're lamenting?
>
No, my criticism is against the added complexity which makes the
modification of git increasingly difficult with every new release. It's a
pretty limited use case of the entire package, I'm sure, but one of the
major advantages that I saw in git early on was the ability to tailor it
to your own personal needs very easily with some simple shell knowledge
and enough C that was required at the time.
> Some C->shell conversions may have made the code "longer and less
> traceable." However, many of those conversions caused the code to be
> shorter (because communication between C functions is simpler than going
> over pipes, and because anything involving a data structure more complex
> than a string is difficult in the shell) and more robust (fewer
> opportunities for quoting/parsing errors, and none of the shell gotchas
> like missing the error code in "foo | bar").
>
You're ignoring the advantageous nature of the shell with regard to git.
The shell is so much better prepared to deal with information managers by
nature than the C programming language. It's not a matter of shorter
code, per se, it's about the developer's ability to make small changes to
the operation of the information manager on demand to tailor to his or her
_current_ needs. For any experienced shell programmer it is so much
easier to go in and change an option or pipe to a different command or
comment out a simple shell command in a .sh file than editing the C code.
And sometimes it's necessary to have several different variations of that
command which is very easy with slightly renamed .sh files instead of
adding on more and more flags to commands that have become so complex at
this point that it's difficult to know the basics of how to manage a
project.
This all became very obvious when the tutorials came out on "how to use
git in 20 commands or less" effectively. These tutorials shouldn't need
to exist with an information manager that started as a quick, efficient,
and _simple_ project. You're treating git development in the same light
as you treat Linux development; let's be honest and say that 99% of the
necessary git functionality was there almost a year ago and ever since
nothing of absolute necessity has been added that serious developers care
about in a revision control system. Look at LKML, nobody is waiting on
these new releases and upgrading to them when they're announced. And this
is the community that git has _targeted_. Most other projects don't care
about the syntactics of sign-off lines and acked-by lines and format-patch
like the git community does.
> Do you have any specific reason to believe that the git code is of worse
> quality now than it was before?
>
Absolutely. I think I've actually documented that fairly well. Back in
the day git was a very concise, well-written package. Today, a tour
through the source code for the latest release leaves a lot to be desired
for any serious C programmer.
> Is there something you used to do with git that you no longer can? Is
> there a reason you can't ignore the newer commands?
>
Functionality wise, no. But in terms of being able to _customize_ my
version of git depending on how I want to use it, I've lost hope on the
whole idea. It's a shame too because it appears as though the original
vision was one of efficiency and simplicity. I would say that git-1.2.4
is my package of preference with some slight tweaking in the branching
department.
I really do miss the old git.
^ permalink raw reply
* Re: VCS comparison table
From: Jeff King @ 2006-10-25 8:48 UTC (permalink / raw)
To: David Rientjes; +Cc: Linus Torvalds, Lachlan Patrick, bazaar-ng, git
In-Reply-To: <Pine.LNX.4.64N.0610241300450.8112@attu4.cs.washington.edu>
On Tue, Oct 24, 2006 at 01:12:52PM -0700, David Rientjes wrote:
> And I would prefer the opposite because we're talking about git. As an
> information manager, it should be seen and not heard. Nobody is going to
> spend their time to become a git or CVS or perforce expert. As an
> individual primarily interested in development, I should not be required
> to learn command lines for dozens of different git-specific commands to do
> my job quickly and effectively. I would opt for a much more simpler
> approach and deal with shell scripting for many of these commands because
> I'm familiar with them and I can pipe any command with the options I
> already know and have used before to any other command.
I don't understand how converting shell scripts to C has any impact
whatsoever on the usage of git. The plumbing shell scripts didn't go
away; you can still call them and they behave identically.
Is there some specific change in functionality that you're lamenting?
> As a developer on Linux based systems, I should not need to deal with
> code in a revision control system that is longer and less traceable
> because the authors of that system decided they wanted to support Windows
> too. Moving away from the functionality that the shell provides is a
> mistake for a system such as git where it could be so advantageous because
> of the inherent nature of git as an information manager.
Some C->shell conversions may have made the code "longer and less
traceable." However, many of those conversions caused the code to be
shorter (because communication between C functions is simpler than going
over pipes, and because anything involving a data structure more complex
than a string is difficult in the shell) and more robust (fewer
opportunities for quoting/parsing errors, and none of the shell gotchas
like missing the error code in "foo | bar").
Do you have any specific reason to believe that the git code is of worse
quality now than it was before?
> This is the reason why I was a fan of git long ago and used it for my own
> needs before tons of unnecessary features and unneeded complexity was
> added on.
Is there something you used to do with git that you no longer can? Is
there a reason you can't ignore the newer commands?
^ permalink raw reply
* Re: [PATCH 2/3] gitweb: Filter out commit ID from @difftree in git_commit and git_commitdiff
From: Jakub Narebski @ 2006-10-25 8:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1woxf1v9.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> Filter out commit ID output that git-diff-tree adds when called with
>> only one <tree-ish> (not only for --stdin) in git_commit and
>> git_commitdiff.
>
> I initially wondered why this, or other existing such sripping,
> is necessary in the first place.
>
> The collected result is given to git_difftree_body() and it
> feeds parse_difftree_raw_line() with it. Interestingly enough,
> it _is_ prepared to handle the line with the commit object
> name.
Perhaps I was overeager in adding that. The only place it was used
was git_tree_blame in the proof-of-concept/RFC patch which added
"tree_blame" view, and even there it was discarded solution: using
git-diff-tree can give only commit which changed the file to current
version; it cannot find commit which changed tree/directory (latest
commit which changed any of its files).
This can be useful if at any time we need to parse git-diff-tree --stdin
output.
> However, the very initial part of git_difftree_body assumes that
> the array it gets does not have the commit object name (i.e. it
> counts the array members and says "N files changed").
The same is true for git_patchset_body. Moreover if I remember correctly
they count elements of @difftree array (or do equivalent of counting)
_before_ parsing.
> So I think your change is probably a good one, but I suspect you
> probably are better off to make parse_difftree_raw_line() to
> barf when it gets the commit object name to make sure that all
> callers strip it at the same time;
I'd rather not do that, and leave parse_difftree_raw_line generic.
> better yet, perhaps you can
> have a single function that invokes git-diff-tree -r (with
> different parameters) and returns the result that is already
> only the difftree body lines?
That would be good idea... if not for the fact that git_commitdiff
uses --patch-with-raw format... but that would make it only slightly
more complicated (strip commit-id, or rather tree-ish from output,
and stop on end of raw part i.e. on first empty line).
I'll do that (unless someone else would do this first).
--
Jakub Narebski
^ permalink raw reply
* an option to make "git-diff Z A" prints Z's diff before A's
From: Jim Meyering @ 2006-10-25 7:15 UTC (permalink / raw)
To: git
Hello,
In a recent patch set I prepared, I placed the names of the
more relevant files at the front of the list given to "git-diff".
So I was surprised to see diff output in which the blocks of output
are sorted by file name. The parts I'd tried to put at the "top"
ended up being buried in the latter part of the patch.
Here's a small test case:
mkdir d && cd d && touch x y && git-init-db
git-add x y && git-commit -m. x y
echo a > x && echo a > y
git-diff y x|grep '^d'
I expected this git-diff output, with "y's" diff first:
diff --git a/y b/y
diff --git a/x b/x
but got this, where x's come first:
diff --git a/x b/x
diff --git a/y b/y
I know about the -O<orderfile> option, and it can make git-diff do
what I want, but only if I first create a separate file containing
the names that I'm already providing to git-diff in the very same order.
Is there an easier way?
If not, would you be amenable to a new option enabling this behavior
without requiring a temporary file?
^ permalink raw reply
* Re: [PATCH] Fix regression tests on Cygwin
From: Lars Hjemli @ 2006-10-25 6:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin
In-Reply-To: <7vods1dmnu.fsf@assigned-by-dhcp.cox.net>
On 10/25/06, Junio C Hamano <junkio@cox.net> wrote:
> Junio C Hamano <junkio@cox.net> writes:
>
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >
> >> On Mon, 23 Oct 2006, Lars Hjemli wrote:
> >>
> >>> On Cygwin, "make test" failes due to missing ".exe" a couple of places.
> >>
> >> Last time I made "test" on cygwin, it did not complain.
> >
> > Same here (W2k, fairly up-to-date git, installed on local NTFS
> > disk).
Well, then it's probably my cygwin-environment that is broken (make
test used to work for me too...)
Sorry for the noise
--
^ permalink raw reply
* Re: git-*arch* in git-arch rpm
From: Junio C Hamano @ 2006-10-25 5:35 UTC (permalink / raw)
To: Gerrit Pape; +Cc: git
In-Reply-To: <20061024200211.17221.qmail@9f622d681978b5.315fe32.mid.smarden.org>
Gerrit Pape <pape@smarden.org> writes:
> Hi, there're two programs in the git-arch rpm that shouldn't be there:
>
> $ rpm -qlp git-arch-1.4.3.2-1.i386.rpm
> /usr/bin/git-archimport
> /usr/bin/git-archive
> /usr/bin/git-upload-archive
> /usr/share/doc/git-arch-1.4.3.2
> /usr/share/doc/git-arch-1.4.3.2/git-archimport.html
> /usr/share/doc/git-arch-1.4.3.2/git-archimport.txt
> /usr/share/doc/git-arch-1.4.3.2/git-archive.html
> /usr/share/doc/git-arch-1.4.3.2/git-archive.txt
> /usr/share/doc/git-arch-1.4.3.2/git-upload-archive.html
> /usr/share/doc/git-arch-1.4.3.2/git-upload-archive.txt
> /usr/share/man/man1/git-archimport.1.gz
> /usr/share/man/man1/git-archive.1.gz
> /usr/share/man/man1/git-upload-archive.1.gz
> $
>
> Regards, Gerrit.
So we need at least this?
diff --git a/git.spec.in b/git.spec.in
index 9b1217a..b61a338 100644
--- a/git.spec.in
+++ b/git.spec.in
@@ -126,10 +126,10 @@ # These are no files in the root package
%files arch
%defattr(-,root,root)
-%doc Documentation/*arch*.txt
-%{_bindir}/*arch*
-%{!?_without_docs: %{_mandir}/man1/*arch*.1*}
-%{!?_without_docs: %doc Documentation/*arch*.html }
+%doc Documentation/git-archimport.txt
+%{_bindir}/git-archimport
+%{!?_without_docs: %{_mandir}/man1/git-archimport.1*}
+%{!?_without_docs: %doc Documentation/git-archimport.html }
%files email
%defattr(-,root,root)
^ permalink raw reply related
* Re: Default modules to load ...
From: Linus Torvalds @ 2006-10-25 4:58 UTC (permalink / raw)
To: Sean; +Cc: Matthias Hopf, Alan Coopersmith, xorg, Git Mailing List
In-Reply-To: <BAYC1-PASMTP013A64CB1BD217DE7EE26AAE010@CEZ.ICE>
On Tue, 24 Oct 2006, Sean wrote:
>
> Add Linus to CC so maybe you'll get better answers than I can offer.
The git list is probably even better.. Added to the Cc:
> > Hm. And why don't I find this in my regularly cloned and updated git
> > repository? I just noted that I wouldn't find this commit after a
> > 'git-pull', but it would after a 'git-pull -t'.
>
> "Git-pull -t" pulls down all remote tags (regardless of which branch
> they're on) and then grabs all the commits they point to. But it
> won't actually pull down the full branch references. Typically,
> you don't ever need to use "-t".
Correct.
Normally, git only tracks the branches you _asked_ it to track. It will
follow any tags that happen along those branches, but it won't follow
branches you haven't asked it to follow.
The reason is actually very simple: people track different things, and
there is _not_ a 1:1 "local repository" to "parent repository" tracking.
It's quite possible (and even sensible) to track two _different_ remote
repositories in the same local repository, and adding branches just
because the remote repository has a branch that you don't track, would
actually be really _wrong_.
> "Git-pull" pulls down all the new commits for the branches you're
> following, and then any tags associated with any of the commits
> you pulled.
Yes, again with the exception that it's limited to just branches you share
with _that_ repository. This is important to understand not because it is
important in itself, but because it explains the behaviour. Once you
realize that there's not any real 1:1 relationship, the git behaviour
makes sense, and anythign else would actually be a bad idea.
That said, we could possibly try to introduce a special _flag_ saying "add
new branches from this remote repository automatically", if that is
actually a common issue.
> > So this basically boils down to the question:
> >
> > How on earth am I supposed to keep up with an upstream repository, if
> > 'git-pull -t' is not doing enough? Nobody can't be suggesting doing a
> > new git-clone all the time...
>
> You shouldn't really ever need "git-pull -t"; just use "git pull". It will
> automatically grab all the tags you need.
>
> But you will need to explicitly add new branches into your repo if you
> want to follow them. Perhaps Git could make this easier.
It actually is very easy already. You just need to be aware of the new
branch you want to track (which you can either be when somebody just
_tells_ you about it, or you can figure it out with "git ls-remote"),
and then you just do
git fetch origin remotebranch:localbranch
and you now have that branch locally.
Now, if you want to continue to _track_ that branch, you probably want to
just tell git so explicitly, and the easiest way tends to just edit the
".git/remotes/origin" file, which has such a simple format that I don't
think you even need to read the documentation, and you will just _guess_
what you should do.
But yeah, if somebody wants to send Junio a
git addbranch
script (a line or two of shell), go wild. It should be easy, and you'll
get the satisfaction of being able to use a command that you know you
wrote yourself! It really isn't very complicated.
^ permalink raw reply
* Re: [PATCH] Fix regression tests on Cygwin
From: Junio C Hamano @ 2006-10-25 4:50 UTC (permalink / raw)
To: Lars Hjemli; +Cc: git, Johannes Schindelin
In-Reply-To: <7vwt6pdn46.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>> On Mon, 23 Oct 2006, Lars Hjemli wrote:
>>
>>> On Cygwin, "make test" failes due to missing ".exe" a couple of places.
>>
>> Last time I made "test" on cygwin, it did not complain.
>
> Same here (W2k, fairly up-to-date git, installed on local NTFS
> disk).
... and more importantly, with fairly up-to-date Cygwin.
^ permalink raw reply
* Re: [PATCH] Fix bad usage of mkpath in builtin-branch.sh
From: Junio C Hamano @ 2006-10-25 4:46 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <7vac3lf3jl.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Petr Baudis <pasky@suse.cz> writes:
>
>> I have made my fair share of inadverent mode changes as well (I don't
>> even know how that *happenned*), and I don't seem to be alone; since
>> this is something you are doing only rarely anyway, perhaps we should
>> try to make mode changes more visible?
>
> Well we already do and that's how I noticed.
Ah, sorry, I think I misunderstood you.
Did you mean something like this?
diff --git a/git-commit.sh b/git-commit.sh
index 5b1cf85..8bae734 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -629,4 +629,7 @@ if test -x "$GIT_DIR"/hooks/post-commit
then
"$GIT_DIR"/hooks/post-commit
fi
+
+test "$ret" = 0 && git-diff-tree --summary --root --no-commit-id HEAD
+
exit "$ret"
^ permalink raw reply related
* Re: [PATCH] Fix regression tests on Cygwin
From: Junio C Hamano @ 2006-10-25 4:40 UTC (permalink / raw)
To: Lars Hjemli; +Cc: git, Johannes Schindelin
In-Reply-To: <Pine.LNX.4.63.0610241653020.2106@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Mon, 23 Oct 2006, Lars Hjemli wrote:
>
>> On Cygwin, "make test" failes due to missing ".exe" a couple of places.
>
> Last time I made "test" on cygwin, it did not complain.
Same here (W2k, fairly up-to-date git, installed on local NTFS
disk).
^ permalink raw reply
* Re: [PATCH 2/3] gitweb: Filter out commit ID from @difftree in git_commit and git_commitdiff
From: Junio C Hamano @ 2006-10-25 4:36 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200610241354.49396.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Filter out commit ID output that git-diff-tree adds when called with
> only one <tree-ish> (not only for --stdin) in git_commit and
> git_commitdiff.
I initially wondered why this, or other existing such sripping,
is necessary in the first place.
The collected result is given to git_difftree_body() and it
feeds parse_difftree_raw_line() with it. Interestingly enough,
it _is_ prepared to handle the line with the commit object
name.
However, the very initial part of git_difftree_body assumes that
the array it gets does not have the commit object name (i.e. it
counts the array members and says "N files changed").
So I think your change is probably a good one, but I suspect you
probably are better off to make parse_difftree_raw_line() to
barf when it gets the commit object name to make sure that all
callers strip it at the same time; better yet, perhaps you can
have a single function that invokes git-diff-tree -r (with
different parameters) and returns the result that is already
only the difftree body lines?
^ permalink raw reply
* Re: [PATCH] Fix bad usage of mkpath in builtin-branch.sh
From: Junio C Hamano @ 2006-10-25 4:00 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20061024113806.GB20017@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Dear diary, on Tue, Oct 24, 2006 at 08:46:49AM CEST, I got a letter
> where Junio C Hamano <junkio@cox.net> said that...
>> Lars Hjemli <hjemli@gmail.com> writes:
>>
>> > diff --git a/builtin-branch.c b/builtin-branch.c
>> > index ffc2db0..f86bf68 100755
>>
>> I've already fixed up this perm-mode breakage (and other
>> breakages, possibly) so when I am done with these patches
>> tonight please resync with me.
>
> I have made my fair share of inadverent mode changes as well (I don't
> even know how that *happenned*), and I don't seem to be alone; since
> this is something you are doing only rarely anyway, perhaps we should
> try to make mode changes more visible?
Well we already do and that's how I noticed.
^ permalink raw reply
* Re: [PATCH qgit] Change also tag marks when changing graph size
From: Josef Weidendorfer @ 2006-10-25 2:20 UTC (permalink / raw)
To: Marco Costalba; +Cc: Git Mailing List
In-Reply-To: <e5bfff550610241245r73b594ftf2cd39f4194b5411@mail.gmail.com>
On Tuesday 24 October 2006 21:45, Marco Costalba wrote:
> Quoting from your last e-mail:
> "The new painting code regroups the drawing commands in
> multiple switch-statements to prepare for far simpler code
> with booleans for different elements, and not one type only."
>
> Indeed it's not clear to me what the above line means exactly, it just
> smells like there is something more cooking.
Ah, yes ;-)
Currently, the drawing code knows how a full part of the graph
should be drawn, with circle, rects, lines.
Now, with direct drawing, this "knowledge" can be moved to graph
layout time, which can generate info whether a circle or rect should
be drawn. Making drawing a little bit faster, and simpler.
I am not sure if it is worth it, but this way, the drawing code could
be the same e.g. for different graph drawing algorithms (like gitk).
> > Now that everything is drawn directly, the question is what to do with
> > the new flexibility. E.g. we _could_ implement different
> > graph drawing algorithms next to the original qgit one,
> > e.g. mimicking gitk.
>
> One little secret of current algorithm is that it just needs to know
> the "state" of previous revision graph to calculate the next one. (see
> Git::updateLanes() and lanes.cpp), it's a kind of a "rasterized" graph
> drawing, i.e. line by line.
>
> I didn't studied gitk in deep but it seems a little bit less simpler.
> Anyway if you are interested it's for sure worth trying ;-)
I will have a look.
Current qgit layout gets really extremely wide e.g. with the kernel.
Some ideas:
* Put lanes to the right if possible
* If a branch has no commit for more than e.g. 50 entries, it's better to
draw an arrow and get rid of the lane at all.
By clicking on an arrow head, we could rearrange the commit ordering
a little bit so that commits on the given branch move in a way that
we always see the context on this branch.
* Collapsing parts of the graph into mega-commits, e.g.
- straight commit lines
- short topic branches forking from and merging into a branch
Josef
>
> Marco
>
^ permalink raw reply
* Re: [PATCH] xdiff: Match GNU diff behaviour when deciding hunk comment worthiness of lines
From: Junio C Hamano @ 2006-10-25 2:18 UTC (permalink / raw)
To: Horst H. von Brand; +Cc: Petr Baudis, git
In-Reply-To: <200610250133.k9P1XSVf006467@laptop13.inf.utfsm.cl>
"Horst H. von Brand" <vonbrand@inf.utfsm.cl> writes:
> Petr Baudis <pasky@suse.cz> wrote:
>> This removes the '#' and '(' tests and adds a '$' test instead although I
>> have no idea what it is actually good for - but hey, if that's what GNU
>> diff does...
>
> $ starts a shell (or Perl) variable...
>
>> Pasky only went and did as Junio sayeth.
>
> Horst adds a guesse...
If I have to guess, I think that is from VMS.
^ permalink raw reply
* Re: [RFC] git-split: Split the history of a git repository by subdirectories and ranges
From: Junio C Hamano @ 2006-10-25 2:13 UTC (permalink / raw)
To: Josh Triplett; +Cc: git
In-Reply-To: <453EC505.7060807@freedesktop.org>
Josh Triplett <josh@freedesktop.org> writes:
> Junio C Hamano wrote:
>
>> The only thing left for us to decide is if reporting the true
>> parenthood like the current --pretty=raw makes sense (if so we
>> need to keep it and introduce --pretty=rawfish).
>>
>> The only in-tree user of --pretty=raw seems to be git-svn but it
>> only looks at path-unlimited log/rev-list from one given commit,
>> so the only difference between dumping what is recorded in the
>> commit object and listing what parents we _think_ the commit has
>> is what we read from grafts. I think we are safe to just "fix"
>> the behaviour of --pretty=raw
>
> I actually think I want to look further into the idea of just using git
> --pretty=raw --parents -- $project, and see if I can find any corner cases
> where it generates a different history than what we want.
I do not mind _coding_ the --pretty=rawfish change if needed but
I do not think it is necessary, which is pretty good news.
After I wrote the message I realized that I probably do not have
to do anything, since --parents would give you the rewritten
parents already anyway.
^ permalink raw reply
* Re: [RFC] git-split: Split the history of a git repository by subdirectories and ranges
From: Josh Triplett @ 2006-10-25 1:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vu01tfe6u.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 3067 bytes --]
Junio C Hamano wrote:
> Josh Triplett <josh@freedesktop.org> writes:
>> Linus Torvalds wrote:
>>> And yes, that's done by the core revision parsing code, so when you do
>>>
>>> git log --full-history --parents -- $project
>>>
>>> you do get the rewritten parent output (of course, it's not actually
>>> _simplified_, so you get a fair amount of duplicate parents etc which
>>> you'd still have to simplify and which don't do anything at all).
>>>
>>> Without the "--full-history", you get a simplified history, but it's
>>> likely to be _too_ simplified for your use, since it will not only
>>> collapse multiple identical parents, it will also totally _remove_ parents
>>> that don't introduce any new content.
>> Considering that git-split does exactly that (remove parents that don't
>> introduce new content, assuming they changed things outside the
>> subtree), that might actually work for us. I just checked, and the
>> output of "git log --parents -- $project" on one of my repositories
>> seems to show the same sequence of commits as git log --parents on the
>> head commit printed by git-split $project (apart from the rewritten
>> sha1s), including elimination of irrelevant merges.
>
> So one potential action item that came out from this discussion
> for me is to either modify --pretty=raw (or add --pretty=rawish)
> that gives the rewritten parents instead of real parents? With
> that, you can drop the code to simplify ancestry by hand in your
> loop, and also you do not have to do the grafts inforamation
> yourself either?
>
> If that is the case I'd be very happy.
>
> The only thing left for us to decide is if reporting the true
> parenthood like the current --pretty=raw makes sense (if so we
> need to keep it and introduce --pretty=rawfish).
>
> The only in-tree user of --pretty=raw seems to be git-svn but it
> only looks at path-unlimited log/rev-list from one given commit,
> so the only difference between dumping what is recorded in the
> commit object and listing what parents we _think_ the commit has
> is what we read from grafts. I think we are safe to just "fix"
> the behaviour of --pretty=raw
I actually think I want to look further into the idea of just using git
--pretty=raw --parents -- $project, and see if I can find any corner cases
where it generates a different history than what we want. This combination of
options seems like it provides everything we need: redundant history
simplification, parent rewriting based on simplification and grafts, and easy
parsing. If the only case in which it differs occurs when you have two
distinct commits with identical trees, I don't know that I care too much; that
particular scenario seems unlikely to occur in any of the trees I care about,
and any sane simplification behavior for it seems OK. :) As long as it runs
correctly with various ancestor/descendant/cousin/unrelated relationships
between merged branches (which I want to test further), I think it will do the
job nicely.
- Josh Triplett
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply
* Re: [PATCH] xdiff: Match GNU diff behaviour when deciding hunk comment worthiness of lines
From: Horst H. von Brand @ 2006-10-25 1:33 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20061025002855.4738.1088.stgit@machine.or.cz>
Petr Baudis <pasky@suse.cz> wrote:
> This removes the '#' and '(' tests and adds a '$' test instead although I
> have no idea what it is actually good for - but hey, if that's what GNU
> diff does...
$ starts a shell (or Perl) variable...
> Pasky only went and did as Junio sayeth.
Horst adds a guesse...
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
^ permalink raw reply
* [PATCH] xdiff: Match GNU diff behaviour when deciding hunk comment worthiness of lines
From: Petr Baudis @ 2006-10-25 0:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmz7lfdwj.fsf@assigned-by-dhcp.cox.net>
This removes the '#' and '(' tests and adds a '$' test instead although I have
no idea what it is actually good for - but hey, if that's what GNU diff does...
Pasky only went and did as Junio sayeth.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
xdiff/xemit.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/xdiff/xemit.c b/xdiff/xemit.c
index 714c563..4139d55 100644
--- a/xdiff/xemit.c
+++ b/xdiff/xemit.c
@@ -86,8 +86,7 @@ static void xdl_find_func(xdfile_t *xf,
if (len > 0 &&
(isalpha((unsigned char)*rec) || /* identifier? */
*rec == '_' || /* also identifier? */
- *rec == '(' || /* lisp defun? */
- *rec == '#')) { /* #define? */
+ *rec == '$')) { /* mysterious GNU diff's invention */
if (len > sz)
len = sz;
^ permalink raw reply related
* Re: VCS comparison table
From: Matthew D. Fuller @ 2006-10-25 0:27 UTC (permalink / raw)
To: David Lang; +Cc: Linus Torvalds, bazaar-ng, git
In-Reply-To: <Pine.LNX.4.63.0610241038060.10841@qynat.qvtvafvgr.pbz>
On Tue, Oct 24, 2006 at 11:03:20AM -0700 I heard the voice of
David Lang, and lo! it spake thus:
>
> it sounded like you were saying that the way to get the slices of
> the DAG was to use branches in bzr. [...]
I'm not entirely sure I understand what you mean here, but I think
you're saying "Nobody's written the code in bzr to show arbitrary
slices of the DAG", which is true TTBOMK.
> everyone agrees that bzr supports the Star topology. Most people
> (including bzr people) seem to agree that currently bzr does not
> support the Distributed topology.
I think this statement arouses so much grumbling because (a) bzr does
support such a lot better than often seems implied, (b) where it
doesn't, the changes needed to do so are relatively minor (often
merely cosmetic), and (c) disagreement over whether some of the
qualifications included for 'distributed' are really fundamental.
> it's just fine for bzr to not support all possible topologies,
I think there's a real intent for bzr TO support at least all common
topologies. I'll buy that current development has focused more on
[relatively] simple topologies than the more wildly complex ones. I
look forward to more addressing of the less common cases as the tool
matures, and I think a lot of this thread will be good material to
work with as that happens. It's just the suggestion that providing
fruit for simple topologies _necessarily_ prejudices against complex
ones that I find so onerous.
> (besides everyone understanding each other)
That's a good enough reason for me. Before this thread, I wasn't
interested in using git. I'm still not, but now I understand much
better /why/ I'm not. And when (I'm sure it'll happen sooner or
later) some project I follow picks up using git, I'll have enough
grounding in the tool's mental model to work with it when I have to.
--
Matthew Fuller (MF4839) | fullermd@over-yonder.net
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
^ permalink raw reply
* Re: [RFC] git-split: Split the history of a git repository by subdirectories and ranges
From: Jakub Narebski @ 2006-10-25 0:19 UTC (permalink / raw)
To: git
In-Reply-To: <7vu01tfe6u.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> So one potential action item that came out from this discussion
> for me is to either modify --pretty=raw (or add --pretty=rawish)
> that gives the rewritten parents instead of real parents? With
> that, you can drop the code to simplify ancestry by hand in your
> loop, and also you do not have to do the grafts inforamation
> yourself either?
>
> If that is the case I'd be very happy.
>
> The only thing left for us to decide is if reporting the true
> parenthood like the current --pretty=raw makes sense (if so we
> need to keep it and introduce --pretty=rawfish).
>
> The only in-tree user of --pretty=raw seems to be git-svn but it
> only looks at path-unlimited log/rev-list from one given commit,
> so the only difference between dumping what is recorded in the
> commit object and listing what parents we _think_ the commit has
> is what we read from grafts. I think we are safe to just "fix"
> the behaviour of --pretty=raw
>
> Comments?
The name --pretty=raw suggest output of info directly from commit object,
but perhaps that just me (--pretty=rawish or ==pretty=headers).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] xdiff: Do not consider lines starting by # hunkworthy
From: Jakub Narebski @ 2006-10-25 0:17 UTC (permalink / raw)
To: git
In-Reply-To: <20061025000708.2753.74523.stgit@machine.or.cz>
Petr Baudis wrote:
> - *rec == '(' || /* lisp defun? */
> - *rec == '#')) { /* #define? */
> + *rec == '(')) { /* #define? */
> if (len > sz)
Shouldn't it be:
+ *rec == '(')) { /* lisp defun? */
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] xdiff: Do not consider lines starting by # hunkworthy
From: Junio C Hamano @ 2006-10-25 0:16 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20061025000708.2753.74523.stgit@machine.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> This will be probably controversial but in my personal experience, the
> amount of time this is the right thing to do because of #defines is negligible
> compared to amount of time it is wrong, especially because of #ifs and #endifs
> in the middle of functions and also because of comments at the line start when
> it concerns non-C files.
>
> Signed-off-by: Petr Baudis <pasky@suse.cz>
> ---
>
> xdiff/xemit.c | 3 +--
> 1 files changed, 1 insertions(+), 2 deletions(-)
>
> diff --git a/xdiff/xemit.c b/xdiff/xemit.c
> index 714c563..4f20075 100644
> --- a/xdiff/xemit.c
> +++ b/xdiff/xemit.c
> @@ -86,8 +86,7 @@ static void xdl_find_func(xdfile_t *xf,
> if (len > 0 &&
> (isalpha((unsigned char)*rec) || /* identifier? */
> *rec == '_' || /* also identifier? */
> - *rec == '(' || /* lisp defun? */
> - *rec == '#')) { /* #define? */
> + *rec == '(')) { /* #define? */
> if (len > sz)
> len = sz;
> if (len && rec[len - 1] == '\n')
I'd either omit the opening parenthesis or fix the comment ;-).
More seriously, I'd rather just match default GNU diff behaviour
to use isalpha, underscore or '$'. I do not particularly like
to have '$' but I feel it is the easiest to match a prior art in
cases like this because I do not have to defend my position when
somebody says "Why do you include '#'??? It makes no sense!".
Since I do not care too much about it, being able to just say
"Well we match what GNU diff does by default." is a good thing.
^ permalink raw reply
* Re: [RFC] git-split: Split the history of a git repository by subdirectories and ranges
From: Junio C Hamano @ 2006-10-25 0:10 UTC (permalink / raw)
To: git; +Cc: Josh Triplett
In-Reply-To: <453D17B5.6070203@freedesktop.org>
Josh Triplett <josh@freedesktop.org> writes:
> Linus Torvalds wrote:
>>
>> And yes, that's done by the core revision parsing code, so when you do
>>
>> git log --full-history --parents -- $project
>>
>> you do get the rewritten parent output (of course, it's not actually
>> _simplified_, so you get a fair amount of duplicate parents etc which
>> you'd still have to simplify and which don't do anything at all).
>>
>> Without the "--full-history", you get a simplified history, but it's
>> likely to be _too_ simplified for your use, since it will not only
>> collapse multiple identical parents, it will also totally _remove_ parents
>> that don't introduce any new content.
>
> Considering that git-split does exactly that (remove parents that don't
> introduce new content, assuming they changed things outside the
> subtree), that might actually work for us. I just checked, and the
> output of "git log --parents -- $project" on one of my repositories
> seems to show the same sequence of commits as git log --parents on the
> head commit printed by git-split $project (apart from the rewritten
> sha1s), including elimination of irrelevant merges.
So one potential action item that came out from this discussion
for me is to either modify --pretty=raw (or add --pretty=rawish)
that gives the rewritten parents instead of real parents? With
that, you can drop the code to simplify ancestry by hand in your
loop, and also you do not have to do the grafts inforamation
yourself either?
If that is the case I'd be very happy.
The only thing left for us to decide is if reporting the true
parenthood like the current --pretty=raw makes sense (if so we
need to keep it and introduce --pretty=rawfish).
The only in-tree user of --pretty=raw seems to be git-svn but it
only looks at path-unlimited log/rev-list from one given commit,
so the only difference between dumping what is recorded in the
commit object and listing what parents we _think_ the commit has
is what we read from grafts. I think we are safe to just "fix"
the behaviour of --pretty=raw
Comments?
^ 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