* Re: WIP: asciidoc replacement
From: J. Bruce Fields @ 2007-10-03 13:55 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Sam Vilain, git, msysgit
In-Reply-To: <Pine.LNX.4.64.0710030506360.28395@racer.site>
On Wed, Oct 03, 2007 at 05:23:35AM +0100, Johannes Schindelin wrote:
> On Wed, 3 Oct 2007, Sam Vilain wrote:
> > Johannes Schindelin wrote:
> >
> > > I do not want to depend on more than necessary in msysGit, and
> > > therefore I started to write an asciidoc replacement.
> >
> > It's pretty good, I certainly wouldn't have trouble reading or
> > maintaining it, but I'll give you suggestions anyway.
>
> Thank you very much! (On both accounts...)
>
> > nice work, replacing a massive XML/XSL/etc stack with a small Perl
> > script ;-)
>
> Uhm... It is less capable, though...
By the way, without having looked at your script to see it does, a
couple things I know of that the user manual relies on that other docs
may not as much are automatic table of contents generation, and cross
references.
I'd be similarly inclined to work on improving asciidoc rather than
inventing something new, but I guess it's at least interesting to see
how far your approach gets us.
--b.
^ permalink raw reply
* Re: WIP: asciidoc replacement
From: J. Bruce Fields @ 2007-10-03 13:47 UTC (permalink / raw)
To: David Kastrup
Cc: Wincent Colaiuta, Junio C Hamano, Johannes Schindelin, git,
msysgit
In-Reply-To: <85k5q4v6jb.fsf@lola.goethe.zz>
On Wed, Oct 03, 2007 at 12:25:44PM +0200, David Kastrup wrote:
> Wincent Colaiuta <win@wincent.com> writes:
>
> > El 3/10/2007, a las 10:12, David Kastrup escribió:
> >
> >> What with output in print, HTML, info?
> >
> > Yes, that's still a problem...
> >
> >> Personally, I think it might make sense to just step away from the
> >> AsciiDoc documentation to Docbook: plain text (without cutified
> >> formatting control like in AsciiDoc) can be generated _from_ Docbook.
> >
> > Yes, but editing DocBook (XML) is relatively painful compared to
> > editing plain text.
>
> The problem is that we are not editing plain text, but Docbook source
> masquerading as plain text.
I do a fair amount of editing of the asciidoc source, but 99% of it is
done by just blind imitation of what's already there. I've never
learned docbook (I've barely learned asciidoc, to be honest), and with a
few (now forgotten) exceptions haven't tried to understand how the
toolchain works.
Maybe my experience would be the same with Docbook--I have no idea,
never having worked with it--but if you're suggesting that knowledge of
Docbook is a prerequisite for working with asciidoc, that certainly
hasn't been my experience.
> But it is not all _all_ easily writeable the moment you try to do
> something with _structural_ impact. In fact, it is pretty much
> impossible for anybody except wizards to do that. And when the
> wizards do it, they can't actually document what they have been doing
> since that would mean cluttering the purported "plain text
> documentation" with formatting comments.
I'm not sure what you're talking about here. Example?
--b.
^ permalink raw reply
* Re: git push (mis ?)behavior
From: Karl Hasselström @ 2007-10-03 13:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Wincent Colaiuta, Miles Bader, Pierre Habouzit, git
In-Reply-To: <7v8x6kfobq.fsf@gitster.siamese.dyndns.org>
On 2007-10-03 04:08:09 -0700, Junio C Hamano wrote:
> Karl Hasselström <kha@treskal.com> writes:
>
> > So it all comes down to case (2) mistakes being much harder to fix
> > than case (1) mistakes. Therefore, we should change the default,
> > since doing so makes it safer.
>
> I am not convinced.
>
> I've seen many new people alias "rm" to "rm -i" for this (I'd say
> "false") reasoning to "default to safer", and end up training their
> fingers to say "y" without thinking.
I don't think that's a good analogy here, since no one is proposing
any kind of interactive prompt.
> Also mistakes can cut both ways. Pushing out what you did not intend
> to is what you seem to be worried about more. But not pushing out
> enough and not noticing is an equally bad mistake.
It may be an equally bad mistake, but it's _not_ equally hard to fix.
(And in my book, that means they aren't in fact equally bad.)
You're right that some users will train their fingers to always type
"git push --all" to the point where they will push everything by
mistake even in cases where that's not what they wanted. But the same
thing will happen with the current default for people who almost
always push just a single branch, and train their fingers for that.
And you just said the two mistakes were equally bad. :-)
> People also argue for "default per user". I am not really convinced
> on that point either.
>
> You, an expert, will get asked for help by somebody, walk up to his
> shell prompt, and try to help and teach him by showing you type, and
> then you suddenly notice the command does not work as you expect
> because he set the default differently (because he read that
> configuration option on some web parge). And we will be in such a
> cumbersome to diagnose situation _very_ often if we have per-user
> default on many things.
I'm generally opposed to per-user settings for that reason. Users who
insist can alias "pusha" to "push --all".
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: git-cvsserver commit trouble (unexpected end of file in client)
From: Jan Wielemaker @ 2007-10-03 13:13 UTC (permalink / raw)
To: git
In-Reply-To: <200710031348.50800.wielemak@science.uva.nl>
On Wednesday 03 October 2007 13:48, Jan Wielemaker wrote:
> Hi,
>
> I'm pretty new to GIT. I quickly convinced our project to move to GIT,
> except for one guy that wants to do Windows and CVS :-( I setup a test
> and the checkout works just fine, but commit from cvs doesn't work. The
> details:
>
> * Server: git version 1.5.3.1 compiled on SuSE 10.2, 64-bits
> * Client, both SuSE CVS 1.12.12 and the current WinCVS cvs.exe,
> so it appears irrelevant.
>
> I created a test repository from a papers directory using the sequence
> beloe. (P.s. isn't there a more elegant way to get to a bare shared repo
> from a set of files? I tried (mkdir papers.git && cd papers.git && git
> --bare init --shared=all), but I can't clone an empty bare repository
> (doesn't create anything), so I can't add to it).
>
> % cd ~/tmp/papers
> % git-init
> % git-add .
> % git-commit
> % cd /home/git
> % git-clone --bare --no-hardlinks ~/tmp/papers/ papers.git
> % cd papers.git
> % git-config core.sharedrepository all
> % chmod g+ws `find . -type d`
> % chmod g+w `find . -type f`
>
> Anyway, appears to work fine with GIT to clone, pull and push. Using
> CVS over SSH, I can checkout this just fine, creating HEAD. Now I change
> a file and run "cvs commit" to get:
>
> gollem (2006) 11_> cvs commit -m "test"
> cvs [commit aborted]: end of file from server (consult above messages if
> any)
I start to get a clue. Adding a line
$log->info("Heads: " . `git show-ref --heads`);
I see this in the log:
2007-10-03 14:13:44 : INFO - Heads: 0b7b372d525a4fe7f662996fec9cd11b1038a6be
refs/heads/master
Thus, I though I created the repository the wrong way. Tried again,
following the recipy of
http://www.kernel.org/pub/software/scm/git/docs/cvs-migration.html:
$ mkdir /pub/my-repo.git
$ cd /pub/my-repo.git
$ git --bare init --shared
$ git --bare fetch /home/alice/myproject master:master
Checked out freshly using CVS. No problem. But committing a change,
nothing changed :-( The log output is exactly the same, showing only
refs/heads/master. I'm starting to suspect git-cvsserver afterall, but
the docs suggests it is operational for quite a while. Could someone
give me a clue on what am I missed?
Thanks --- Jan
> I enabled logging and added a few statements to git-cvsserver (line 1203)
>
> $log->info("Start git show-ref -s refs/heads/$state->{module}");
> # Remember where the head was at the beginning.
> my $parenthash = `git show-ref -s refs/heads/$state->{module}`;
> $log->info("parenthash = $parenthash");
> chomp $parenthash;
> if ($parenthash !~ /^[0-9a-f]{40}$/) {
> $log->warn("error 1 pserver cannot find the current HEAD of
> module");
> exit;
> }
>
> Then I get this log output:
>
> ================================================================
> 2007-10-03 12:25:16 : DEBUG - Temporary directory is '/tmp/XwYVFFqjyd'
> 2007-10-03 12:25:16 : DEBUG - req_Root : /home/git/papers.git
> 2007-10-03 12:25:16 : DEBUG - req_Validresponses : ok error Valid-requests
> Referrer Redirect Checked-in New-entry Checksum Co
> py-file Updated Created Update-existing Merged Patched Rcs-diff Mode
> Mod-time Removed Remove-entry Set-static-directory Clear
> -static-directory Set-sticky Clear-sticky Edit-file Template Clear-template
> Notified Module-expansion Wrapper-rcsOption M Mbi
> nary E F MT
> 2007-10-03 12:25:16 : DEBUG - req_validrequests
> 2007-10-03 12:25:16 : DEBUG - SEND : Valid-requests remove add status Entry
> watchers ci tag log co Modified Questionable admi
> n Root history valid-requests Global_option Argumentx annotate
> Valid-responses Unchanged Directory rlog Argument expand-modul
> es diff editors update
> 2007-10-03 12:25:16 : DEBUG - SEND : ok
> 2007-10-03 12:25:16 : DEBUG - req_Globaloption : -q
> 2007-10-03 12:25:16 : DEBUG - Argument : -m
> 2007-10-03 12:25:16 : DEBUG - Argument : test
> 2007-10-03 12:25:16 : DEBUG - Argument : --
> 2007-10-03 12:25:16 : INFO - Setting prepend to '2006/'
> 2007-10-03 12:25:16 : DEBUG - Prepending '2006/' to state|directory
> 2007-10-03 12:25:16 : DEBUG - req_Directory : localdir=.
> repository=/home/git/papers.git/HEAD/2006 path=2006/ directory=2006/
> module=HEAD
> 2007-10-03 12:25:16 : INFO - Received entry line '/README.txt/1.1///'
> => '2006/README.txt'
> 2007-10-03 12:25:16 : DEBUG - Argument : README.txt
> 2007-10-03 12:25:16 : INFO - req_ci : [NULL]
> 2007-10-03 12:25:16 : INFO - Lockless commit start, basing commit
> on '/tmp/XwYVFFqjyd/ud4uGbbUJg', index file is '/tmp/XwYVF
> Fqjyd/3FeXMladmb'
> 2007-10-03 12:25:16 : INFO - Start git show-ref -s refs/heads/HEAD
> 2007-10-03 12:25:16 : INFO - parenthash =
> 2007-10-03 12:25:16 : WARN - error 1 pserver cannot find the current HEAD
> of module
> ================================================================
>
> I don't like the req_ci : [NULL] very much, and the last 3 lines clearly
> shows a problem. I checked
> the latest git repository of git. There is no change to git-cvsserver.perl.
>
> I'm still a bit too newbie to (and not much of a Perl programmer). Does
> anyone has a clue? Do I have
> the wrong version for something? Did I setup the repository wrongly?
>
> Thanks --- Jan
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: merging .gitignore
From: Johan Herland @ 2007-10-03 13:06 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin, Andy Parkins, martin f krafft
In-Reply-To: <Pine.LNX.4.64.0710031314530.28395@racer.site>
On Wednesday 03 October 2007, Johannes Schindelin wrote:
> On Wed, 3 Oct 2007, Johan Herland wrote:
> > - Teach the .gitignore parser to ignore conflict markers (i.e. regard them
> > as comments)
>
> You might be delighted to know that in practice, it works already (because
> you usually do not have a file named "<<<<<< blablub" or "======" or
> ">>>>>> blablub"...
I suspected so... ;)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: merging .gitignore
From: Johannes Schindelin @ 2007-10-03 12:41 UTC (permalink / raw)
To: Johan Herland; +Cc: git, Andy Parkins, martin f krafft
In-Reply-To: <200710031128.56472.johan@herland.net>
Hi,
On Wed, 3 Oct 2007, Johan Herland wrote:
> - Teach the .gitignore parser to ignore conflict markers (i.e. regard them
> as comments)
You might be delighted to know that in practice, it works already (because
you usually do not have a file named "<<<<<< blablub" or "======" or
">>>>>> blablub"...
Ciao,
Dscho
^ permalink raw reply
* git-cvsserver commit trouble (unexpected end of file in client)
From: Jan Wielemaker @ 2007-10-03 11:48 UTC (permalink / raw)
To: git
Hi,
I'm pretty new to GIT. I quickly convinced our project to move to GIT,
except for one guy that wants to do Windows and CVS :-( I setup a test
and the checkout works just fine, but commit from cvs doesn't work. The
details:
* Server: git version 1.5.3.1 compiled on SuSE 10.2, 64-bits
* Client, both SuSE CVS 1.12.12 and the current WinCVS cvs.exe,
so it appears irrelevant.
I created a test repository from a papers directory using the sequence
beloe. (P.s. isn't there a more elegant way to get to a bare shared repo
from a set of files? I tried (mkdir papers.git && cd papers.git && git
--bare init --shared=all), but I can't clone an empty bare repository
(doesn't create anything), so I can't add to it).
% cd ~/tmp/papers
% git-init
% git-add .
% git-commit
% cd /home/git
% git-clone --bare --no-hardlinks ~/tmp/papers/ papers.git
% cd papers.git
% git-config core.sharedrepository all
% chmod g+ws `find . -type d`
% chmod g+w `find . -type f`
Anyway, appears to work fine with GIT to clone, pull and push. Using
CVS over SSH, I can checkout this just fine, creating HEAD. Now I change
a file and run "cvs commit" to get:
gollem (2006) 11_> cvs commit -m "test"
cvs [commit aborted]: end of file from server (consult above messages if any)
I enabled logging and added a few statements to git-cvsserver (line 1203)
$log->info("Start git show-ref -s refs/heads/$state->{module}");
# Remember where the head was at the beginning.
my $parenthash = `git show-ref -s refs/heads/$state->{module}`;
$log->info("parenthash = $parenthash");
chomp $parenthash;
if ($parenthash !~ /^[0-9a-f]{40}$/) {
$log->warn("error 1 pserver cannot find the current HEAD of
module");
exit;
}
Then I get this log output:
================================================================
2007-10-03 12:25:16 : DEBUG - Temporary directory is '/tmp/XwYVFFqjyd'
2007-10-03 12:25:16 : DEBUG - req_Root : /home/git/papers.git
2007-10-03 12:25:16 : DEBUG - req_Validresponses : ok error Valid-requests
Referrer Redirect Checked-in New-entry Checksum Co
py-file Updated Created Update-existing Merged Patched Rcs-diff Mode Mod-time
Removed Remove-entry Set-static-directory Clear
-static-directory Set-sticky Clear-sticky Edit-file Template Clear-template
Notified Module-expansion Wrapper-rcsOption M Mbi
nary E F MT
2007-10-03 12:25:16 : DEBUG - req_validrequests
2007-10-03 12:25:16 : DEBUG - SEND : Valid-requests remove add status Entry
watchers ci tag log co Modified Questionable admi
n Root history valid-requests Global_option Argumentx annotate Valid-responses
Unchanged Directory rlog Argument expand-modul
es diff editors update
2007-10-03 12:25:16 : DEBUG - SEND : ok
2007-10-03 12:25:16 : DEBUG - req_Globaloption : -q
2007-10-03 12:25:16 : DEBUG - Argument : -m
2007-10-03 12:25:16 : DEBUG - Argument : test
2007-10-03 12:25:16 : DEBUG - Argument : --
2007-10-03 12:25:16 : INFO - Setting prepend to '2006/'
2007-10-03 12:25:16 : DEBUG - Prepending '2006/' to state|directory
2007-10-03 12:25:16 : DEBUG - req_Directory : localdir=.
repository=/home/git/papers.git/HEAD/2006 path=2006/ directory=2006/
module=HEAD
2007-10-03 12:25:16 : INFO - Received entry line '/README.txt/1.1///'
=> '2006/README.txt'
2007-10-03 12:25:16 : DEBUG - Argument : README.txt
2007-10-03 12:25:16 : INFO - req_ci : [NULL]
2007-10-03 12:25:16 : INFO - Lockless commit start, basing commit
on '/tmp/XwYVFFqjyd/ud4uGbbUJg', index file is '/tmp/XwYVF
Fqjyd/3FeXMladmb'
2007-10-03 12:25:16 : INFO - Start git show-ref -s refs/heads/HEAD
2007-10-03 12:25:16 : INFO - parenthash =
2007-10-03 12:25:16 : WARN - error 1 pserver cannot find the current HEAD of
module
================================================================
I don't like the req_ci : [NULL] very much, and the last 3 lines clearly shows
a problem. I checked
the latest git repository of git. There is no change to git-cvsserver.perl.
I'm still a bit too newbie to (and not much of a Perl programmer). Does
anyone has a clue? Do I have
the wrong version for something? Did I setup the repository wrongly?
Thanks --- Jan
^ permalink raw reply
* Re: [PATCH] git-init: don't base core.filemode on the ability to chmod.
From: Johannes Sixt @ 2007-10-03 12:19 UTC (permalink / raw)
To: Martin Waitz; +Cc: git
In-Reply-To: <20071003105501.GD7085@admingilde.org>
Martin Waitz schrieb:
> At least on Linux the vfat file system honors chmod calls but does not
> store them permanently (as there is no on-disk format for it).
> So the filemode test which tries to chmod a file thinks that the file
> system does support file modes. This will result in problems when the
> file system gets mounted for the next time and all the executable bits
> are back.
>
> A more reliable test for file systems without filemode support is to
> simply check if new files are created with the executable bit set.
On Windows, we don't get an executable bit at all. Better use both
heuristics, i.e. set core.filemode false if either one diagnoses an
unreliable x-bit.
-- Hannes
^ permalink raw reply
* Re: [PATCH] Add test case for ls-files --with-head
From: Johannes Sixt @ 2007-10-03 12:09 UTC (permalink / raw)
To: Carl Worth; +Cc: Junio C Hamano, Keith Packard, Git Mailing List
In-Reply-To: <87y7ekr86e.wl%cworth@cworth.org>
Carl Worth schrieb:
> +for num in $(seq -f%04g 1 50); do
> + touch sub/file-$num
> + echo file-$num >> expected
> +done
seq is not universally available. Can we have that as
for i in 0 1 2 3 4; do
for j in 0 1 2 3 4 5 6 7 8 9; do
> sub/file-$i$j
echo file-$i$j >> expected
done
done
-- Hannes
^ permalink raw reply
* Re: [msysGit] Re: WIP: asciidoc replacement
From: David Kastrup @ 2007-10-03 12:02 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git, msysgit
In-Reply-To: <Pine.LNX.4.64.0710031239410.28395@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Tue, 2 Oct 2007, Junio C Hamano wrote:
>
>>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>
>> > So here it is: a perl script that does a good job on many .txt files
>> > in Documentation/, although for some it deviates from "make man"'s
>> > output, and for others it is outright broken. It is meant to be run
>> > in Documentation/.
>> >
>> > My intention is not to fix the script for all cases, but to make
>> > patches to Documentation/*.txt themselves, so that they are more
>> > consistent (and incidentally nicer to the script).
>>
>> How you spend your time is up to you, but I need to wonder...
>>
>> - Is "man" format important for msysGit aka Windows
>> environment? I had an impression that their helpfile format
>> were closer to "html" output.
>
> I wanted something that can output both "man" and "html" output (and
> if some suck^Wlos^Wtexi-fan wants to provide it, also a "texi" or
> even "info" backend).
And you have not even talked about print. The thing is that high
quality output is a lot of work (including design and design
decisions) for _every_ _single_ backend. If the only target were
"man" and text, then one would be better off writing as groff source
and be done.
We really can't afford another time sink. That nobody can actually
solve structural problems ("how do we include the man pages as an
appendix in the user manual?") also implies a waste of time, but at
some point of time people just throw up their hands and give up in
disgust.
You propose a larger time sink where people won't be forced to give
up. But we really don't want to waste time reinventing the wheel. It
would be better spent communicating with the wheelbuilders.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [msysGit] Re: WIP: asciidoc replacement
From: Johannes Schindelin @ 2007-10-03 11:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, msysgit
In-Reply-To: <7vprzwhkgd.fsf@gitster.siamese.dyndns.org>
Hi,
On Tue, 2 Oct 2007, Junio C Hamano wrote:
>
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > So here it is: a perl script that does a good job on many .txt files
> > in Documentation/, although for some it deviates from "make man"'s
> > output, and for others it is outright broken. It is meant to be run
> > in Documentation/.
> >
> > My intention is not to fix the script for all cases, but to make
> > patches to Documentation/*.txt themselves, so that they are more
> > consistent (and incidentally nicer to the script).
>
> How you spend your time is up to you, but I need to wonder...
>
> - Is "man" format important for msysGit aka Windows
> environment? I had an impression that their helpfile format
> were closer to "html" output.
I wanted something that can output both "man" and "html" output (and if
some suck^Wlos^Wtexi-fan wants to provide it, also a "texi" or even "info"
backend).
IMHO "man" needs a stricter framework in place, so I went with that.
> - Does it make sense in the longer term for us to maintain
> in-house documentation tools? Can we afford it?
In the long run, I expect only few bugs (and I will try hard to squash
them when they crop up, _and_ make this beast more maintainable whenever
somebody has an idea how to do that).
However, it should definitely help keeping the docs clean, as now nobody
has an excuse to test doc changes a la "I do not have asciidoc, so I do
not know if it works, so please test".
> It appears that we heard about breakages for every minor docbook
> updates, and it is really appealing if we do not have to rely on xsl
> toolchain for manpage generation.
Exactly.
> But if patching the text means making it compatible with the in-house
> script _and_ incompatible with AsciiDoc, hmmm...
No, I do not want it _incompatible_. I want it _stricter_. For example,
you can do this in asciidoc:
This is some paragraph that is indented,
but the funny thing is:
This paragraph:
---------------
is indented all the same!
So one thing I absolutely detest here is that you are free to use one,
two, three or more spaces, or tabs, and asciidoc does the DWIMery of
handling them the same. But _not_ if there was any indentation before
that with _less_ spaces and/or tabs!
Therefore I'd like to enforce strict rules here: Tab it is. One tab per
indentation level. No spaces, no ambiguities.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] git-init: don't base core.filemode on the ability to chmod.
From: Martin Waitz @ 2007-10-03 10:55 UTC (permalink / raw)
To: git
At least on Linux the vfat file system honors chmod calls but does not
store them permanently (as there is no on-disk format for it).
So the filemode test which tries to chmod a file thinks that the file
system does support file modes. This will result in problems when the
file system gets mounted for the next time and all the executable bits
are back.
A more reliable test for file systems without filemode support is to
simply check if new files are created with the executable bit set.
Signed-off-by: Martin Waitz <tali@admingilde.org>
---
builtin-init-db.c | 5 +----
1 files changed, 1 insertions(+), 4 deletions(-)
NOTE: this is only tested on Linux with ext3 and vfat file systems.
I do not know enough about the behaviour of other systems so there
may be regressions.
diff --git a/builtin-init-db.c b/builtin-init-db.c
index 763fa55..fbccacb 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -246,10 +246,7 @@ static int create_default_files(const char *git_dir, const char *template_path)
/* Check filemode trustability */
filemode = TEST_FILEMODE;
if (TEST_FILEMODE && !lstat(path, &st1)) {
- struct stat st2;
- filemode = (!chmod(path, st1.st_mode ^ S_IXUSR) &&
- !lstat(path, &st2) &&
- st1.st_mode != st2.st_mode);
+ filemode = !(st1.st_mode & S_IXUSR);
}
git_config_set("core.filemode", filemode ? "true" : "false");
--
1.5.3.3.8.g367dc7
--
Martin Waitz
^ permalink raw reply related
* Re: [PATCH] Change "refs/" references to symbolic constants
From: Andreas Ericsson @ 2007-10-03 11:30 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, Junio C Hamano, Andy Parkins, git
In-Reply-To: <Pine.LNX.4.64.0710030503520.28395@racer.site>
Johannes Schindelin wrote:
> Hi,
>
> On Tue, 2 Oct 2007, Jeff King wrote:
>
>> On Tue, Oct 02, 2007 at 05:22:23PM -0700, Junio C Hamano wrote:
>>
>>>> strbuf_init(&url);
>>>> strbuf_addf(&url, "%s/objects/pack/pack-%s.idx", repo->base, hex);
>>> Ugh, this typically calls snprintf() twice doesn't it?
>> Yes, it probably does. However, I think it is considerably easier to
>> read and more maintainable. Are you "ugh"ing because of the performance
>> impact (which should be negligible unless this is in a tight loop) or
>> because of the portability problems associated with va_copy?
>
> I wonder, I wonder, if
>
> strbuf_addstr(&url, repo->base);
> strbuf_addstr(&url, "/objects/pack/pack-");
> strbuf_addstr(&url, hex);
> strbuf_addstr(&url, ".idx");
>
> would make anybody else but me happy...
strbuf_addstr_many(&url, repo->base, "/objects/pack/pack-", hex, ".idx", NULL);
is what I'd prefer. It's not overly complicated, requires no *printf(), and doesn't
introduce any new portability issues (va_arg() is C89).
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git-svn merge helper
From: Andreas Ericsson @ 2007-10-03 11:40 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Steven Walter, git
In-Reply-To: <20071003010233.GA8610@atjola.homenet>
Björn Steinbrink wrote:
> On 2007.10.02 20:42:52 -0400, Steven Walter wrote:
>> On Wed, Oct 03, 2007 at 12:38:13AM +0200, Björn Steinbrink wrote:
>>>> The other option is to have a "build" branch. By example:
>>>>
>>>> git checkout build
>>>> git reset --hard master
>>>> git merge mybranch
>>>> make
>>>>
>>>> In that way, I have branch with the latest changes from head and the
>>>> changes from mybranch together. The downside to this method is that you
>>>> may have to repeated resolve merges. Despite the downsides, I find
>>>> these two methods to work quite well.
>>> Thanks, but it makes no difference here, it stil results in a fast
>>> forward. This is a small test case which exhibits the behaviour and
>>> matches my current workflow with git-svn (except for the dcommits):
>>>
>>> git init
>>> echo Hi > file1; git add file1; git commit -m file1
>>> git checkout -b branch
>>> echo Hi > file2; git add file2; git commit -m file2
>>> git checkout master
>>> echo Hi > file3; git add file3; git commit -m file3
>>> git checkout branch
>>> git merge master
>>>
>>> # Then I'd normally do the following which causes a fast forward
>>> #git checkout master
>>> #git merge branch
>>>
>>> # Now I tried this, which also results in a fast-forward:
>>> git checkout -b merge
>>> git reset --hard master
>>> git merge branch
>> I believe you misunderstood my suggestion. In using a "build" branch,
>> you would not merge master into branch, as you did above. Instead, you
>> would create a third, unpublished branch to hold the merge.
>
> Almost though so.
>
>> At the same time, I have a slightly better understanding of what it is
>> you're trying to do. If you are trying to keep up an SVN-like workflow
>> (namely pulling changes from trunk into a branch from time to time),
>> then my solution probably isn't suitable for you. However, you might
>> consider why you actually /need/ to do that, outside of SVN convention.
>
> Due to the same reason for which the branch needs to be public at all,
> there are other people who want to follow it and test it, while there
> are external dependencies that currently change quite often. So I need
> to get the relevant changes from trunk into my branch anyway, even with
> svn conventions put aside (well, unless I force everyone else to merge
> over and over again). And as sometimes others commit to that branch, too
> (you just have to love that), keeping a separate branch for the final
> merge isn't so nice either, as I'd need to constantly cherry-pick those
> changes then and probably get even more conflicts along the way.
>
> That said, Google finally liked some of the search terms that I threw at
> it and revealed a thread [1] from march, where Linus was torn on whether
> or not a --no-fast-forward option should be introduced. That sounds like
> it would help here, any chance of getting such a thing?
>
Is this what you're looking for? It's in the 'next' branch in git.git.
commit d66424c4ac661c69640765260235452499d80378
Author: Lars Hjemli <hjemli@gmail.com>
Date: Mon Sep 24 00:51:45 2007 +0200
git-merge: add --ff and --no-ff options
These new options can be used to control the policy for fast-forward
merges: --ff allows it (this is the default) while --no-ff will create
a merge commit.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git push (mis ?)behavior
From: Wincent Colaiuta @ 2007-10-03 11:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Karl Hasselström, Miles Bader, Pierre Habouzit, git
In-Reply-To: <7v8x6kfobq.fsf@gitster.siamese.dyndns.org>
El 3/10/2007, a las 13:08, Junio C Hamano escribió:
> Also mistakes can cut both ways. Pushing out what you did not
> intend to is what you seem to be worried about more. But not
> pushing out enough and not noticing is an equally bad mistake.
I don't think they're of the same order. If you mistakenly push out
too little you can easily correct it by pushing again. But what do
you do if you push out too much? How do you fix that?
> You, an expert, will get asked for help by somebody, walk up to
> his shell prompt, and try to help and teach him by showing you
> type, and then you suddenly notice the command does not work as
> you expect because he set the default differently (because he
> read that configuration option on some web parge). And we will
> be in such a cumbersome to diagnose situation _very_ often if we
> have per-user default on many things.
True, true.
Cheers,
Wincent
^ permalink raw reply
* Re: [PATCH] Change "refs/" references to symbolic constants
From: Andy Parkins @ 2007-10-03 11:13 UTC (permalink / raw)
To: git; +Cc: Jeff King
In-Reply-To: <200710030850.19614.andyparkins@gmail.com>
On Wednesday 2007 October 03, Andy Parkins wrote:
> I put a comment above the other changes like this in the same file, but
> thought I was being overly verbose putting it in every single time. I'm
> happy to copy the comment around in the file though.
I'm a liar; I remember writing them, but they're not in the patch. Perhaps
they are still in my working tree at home. Anyway; you're point was correct,
I'll find the explanatory comments or write new ones and add them to the
patch.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: git push (mis ?)behavior
From: Benoit SIGOURE @ 2007-10-03 11:10 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: git list
In-Reply-To: <83C5420A-528A-43F0-AF8C-699B85B7AD95@wincent.com>
[-- Attachment #1: Type: text/plain, Size: 3363 bytes --]
On Oct 3, 2007, at 12:25 PM, Wincent Colaiuta wrote:
> El 3/10/2007, a las 10:57, Miles Bader escribió:
>
>> To the extent that a command _is_ "dangerous", there's always a
>> tradeoff
>> between convenience and "danger". Some systems (e.g. those aimed at
>> newbies) might have as a goal to do the absolute minimum with every
>> command and always, always, err on the side of safety. I don't
>> think git
>> is that system.
>
> While much of this debate can be shortcircuited simply by making
> the behaviour configurable, I would like to take you up on the
> point that you raise here.
>
> If we're going to talk about what kind of system Git is then
> consider this:
>
> - it's inherently distributed and this design actively encourages
> users to treat their local repositories as sandboxes where things
> are tried out, perfected, and then pushed out into the public via
> one means or another
>
> - it's built from the ground up to be good at branching and
> merging; this, combined with my previous point, means that users
> are likely to have multiple heads and often some of them will be
> "works in progress" that aren't yet ready for publication
>
> So it's in that light I see accidentally pushing more than you
> thought you would as "dangerous"; when you make this mistake you're
> basically making stuff available that's not yet ready for
> consumption, and by its nature this mistake is basically
> irreversible: you can't really "unpush" what you pushed, you can
> only push out additional amendments which correct it.
>
> So, in this light, when you say:
>
>> What's "dangerous" for newbies, often ends up being what doesn't
>> correspond with their mental model.
>
> I don't know how much it has to do with mental models. I think in
> this case it's a bit simpler than that where you make the mistake
> once or twice and very quickly learn that "git push" means "push
> what's in my repo", not "push only what's on my current branch".
> It's a *very* easy lesson to learn if you get burnt and hardly
> requires any adjustments to ones "mental model".
>
> I personally would be in favour of changing the default because I
> tend to work on a particular branch at a time and then want to push
> *that* out -- generally I'm thinking about one general area or one
> task at a time, and that means one branch at a time; I almost never
> think along the lines of getting all my branches into shape at once
> and then pushing them out in a batch. I think this is more likely
> to be a common pattern, although obviously that remains speculation
> at this point.
>
> Changing the default would be great for people like me; by not
> having to pass additional parameters to git-push I save some
> keystrokes. If I ever want to push everything an "--all" switch
> would do the job. But if people prefer to keep the old default then
> there'll be .gitconfig for people like me. In any case I think more
> people need to speak up on the topic so that we can find out what
> most people really think about changing the default.
>
I completely second all that. I've been using Git for roughly 3
months and have been burnt the same way.
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* Re: git push (mis ?)behavior
From: Junio C Hamano @ 2007-10-03 11:08 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Wincent Colaiuta, Miles Bader, Pierre Habouzit, git
In-Reply-To: <20071003104943.GA3017@diana.vm.bytemark.co.uk>
Karl Hasselström <kha@treskal.com> writes:
> So it all comes down to case (2) mistakes being much harder to fix
> than case (1) mistakes. Therefore, we should change the default, since
> doing so makes it safer.
I am not convinced.
I've seen many new people alias "rm" to "rm -i" for this (I'd
say "false") reasoning to "default to safer", and end up
training their fingers to say "y" without thinking.
Also mistakes can cut both ways. Pushing out what you did not
intend to is what you seem to be worried about more. But not
pushing out enough and not noticing is an equally bad mistake.
People also argue for "default per user". I am not really
convinced on that point either.
You, an expert, will get asked for help by somebody, walk up to
his shell prompt, and try to help and teach him by showing you
type, and then you suddenly notice the command does not work as
you expect because he set the default differently (because he
read that configuration option on some web parge). And we will
be in such a cumbersome to diagnose situation _very_ often if we
have per-user default on many things.
^ permalink raw reply
* Re: WIP: asciidoc replacement
From: Junio C Hamano @ 2007-10-03 10:57 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: David Kastrup, Johannes Schindelin, git, msysgit
In-Reply-To: <1D18C52E-BB96-49EC-97A9-F802D56CAFF5@wincent.com>
Wincent Colaiuta <win@wincent.com> writes:
> Yes, but editing DocBook (XML) is relatively painful compared to
> editing plain text. You either have to rely on a bloated XML-
> validating editor or instead ask your doc authors to manually write
> valid XML (and I totally agree with Terrence Parr that, "XML makes a
> lousy human interface
> "; see <http://www.ibm.com/developerworks/xml/library/x-sbxml.html>
> for his full take).
>
> I know that Linus has argued for AsciiDoc because the source *is* the
> plain text documentation and is therefore easily readable, but for me
> the real benefit lies in the fact that *because* the source is plain
> text it is easily edited (ie. that the source is easily *writeable*),
> and things like documentation patches are very neat with AsciiDoc.
To give credits to where they are due, most of the structure of
the initial documentation was done during the first week of May
2005 by David Greaves while Linus was vacationing, and the first
person who brought up AsciiDoc was Bert Hubert.
http://article.gmane.org/gmane.comp.version-control.git/2323
One thing Linus had to say about the issue from early on, and I
still agree with, is the last paragraph in:
http://article.gmane.org/gmane.comp.version-control.git/2298
There was another thread in the recent past
http://article.gmane.org/gmane.comp.version-control.git/55059
I've seen markdown used elsewhere, and I regularly read pod.
These are both used by other people (I _care_ about good
external support and user community), are readable as straight
text (I personally care more about this than prettyprinted
output), and can be alternative candidates if we consider
switching.
How good are HTML and manpage output support from these (or
other candidates) formats these days? Output to help page
format Windows folks use (I am assuming Mac people are happy as
long as man is available) would be a definite plus.
Another alternative could be to build on AsciiDoc to get manpage
and html output without relying too heavily on docbook
toolchain, and considering the fact that we still seem to be one
of the most important customers listed on its home page, we
might be able to get help from Stuart himself to improve the
situation (I am assuming that mingwgit folks do not have problem
with Python, but I may be mistaken).
In short, although I do appreciate Johannes's and Sam's attempt,
I would really prefer to see us pick some externally maintained
alternative, instead of inventing a homebrew system that we need
to maintain ourselves. It is rumored that git has much higher
developer count vs loc count ratio than many other open source
projects, doing the documentation format is not part of our
project, and I'd rather see them spend time working on git, not
building and maintaining AsciiDoc lookalike.
^ permalink raw reply
* Re: WIP: asciidoc replacement
From: Sam Ravnborg @ 2007-10-03 10:52 UTC (permalink / raw)
To: David Kastrup
Cc: Wincent Colaiuta, Junio C Hamano, Johannes Schindelin, git,
msysgit
In-Reply-To: <85k5q4v6jb.fsf@lola.goethe.zz>
Hi David.
>
> But it is not all _all_ easily writeable the moment you try to do
> something with _structural_ impact. In fact, it is pretty much
> impossible for anybody except wizards to do that. And when the
> wizards do it, they can't actually document what they have been doing
> since that would mean cluttering the purported "plain text
> documentation" with formatting comments.
When I converted part of the kbuild documentation to ascii doc
is was a strightforward excercise.
The txt file was equally readable before and after,
and the generated HTML looks OK.
Up until 3.6 in following link were properly converted:
http://www.ravnborg.org/kbuild/makefiles.html
But I did not convince asciidoc to generate an index - is it this
you refer to as magic?
Using the kbuild doc as my background I would say that with
or without asciidoc there were a requirment for a consistent
style used throughout the file.
And that style was and are simple to use just by copying
relevant examples.
What asciidoc gave me was a simple syntax chack of what I did.
I found wrong references when playing with asciidoc as
one example.
If the asciidoc replacement prove a success for git I would
consider suggesting it for the kernel too.
It would be good to generate some nicer loking online documentation
and here an asii tool like thing would be a help.
Sam
^ permalink raw reply
* Re: git push (mis ?)behavior
From: Karl Hasselström @ 2007-10-03 10:49 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Miles Bader, Pierre Habouzit, Junio C Hamano, git
In-Reply-To: <83C5420A-528A-43F0-AF8C-699B85B7AD95@wincent.com>
On 2007-10-03 12:25:22 +0200, Wincent Colaiuta wrote:
> In any case I think more people need to speak up on the topic so
> that we can find out what most people really think about changing
> the default.
My vote is for changing it.
Both "push the current branch" and "push all branches" have their
uses, and both can be specified explicitly, so no problem there. The
problem arises when a user expects one default but get another. There
are two cases:
1. "push the current branch" is the default, but the user intended
to push all branches. She ends up pushing only a subset of what
she wanted, which is easily fixed once she notices what's
happened.
2. "push all branches" is the default, but the user intended to push
only the current branch. She ends up pushing a superset of what
she wanted, which is not easily fixed if she can't be sure that
no one else has pulled from the public repo before she notices
what's happened.
So it all comes down to case (2) mistakes being much harder to fix
than case (1) mistakes. Therefore, we should change the default, since
doing so makes it safer.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: git push (mis ?)behavior
From: Wincent Colaiuta @ 2007-10-03 10:25 UTC (permalink / raw)
To: Miles Bader; +Cc: Pierre Habouzit, Junio C Hamano, git
In-Reply-To: <buobqbgmv6z.fsf@dhapc248.dev.necel.com>
El 3/10/2007, a las 10:57, Miles Bader escribió:
> To the extent that a command _is_ "dangerous", there's always a
> tradeoff
> between convenience and "danger". Some systems (e.g. those aimed at
> newbies) might have as a goal to do the absolute minimum with every
> command and always, always, err on the side of safety. I don't
> think git
> is that system.
While much of this debate can be shortcircuited simply by making the
behaviour configurable, I would like to take you up on the point that
you raise here.
If we're going to talk about what kind of system Git is then consider
this:
- it's inherently distributed and this design actively encourages
users to treat their local repositories as sandboxes where things are
tried out, perfected, and then pushed out into the public via one
means or another
- it's built from the ground up to be good at branching and merging;
this, combined with my previous point, means that users are likely to
have multiple heads and often some of them will be "works in
progress" that aren't yet ready for publication
So it's in that light I see accidentally pushing more than you
thought you would as "dangerous"; when you make this mistake you're
basically making stuff available that's not yet ready for
consumption, and by its nature this mistake is basically
irreversible: you can't really "unpush" what you pushed, you can only
push out additional amendments which correct it.
So, in this light, when you say:
> What's "dangerous" for newbies, often ends up being what doesn't
> correspond with their mental model.
I don't know how much it has to do with mental models. I think in
this case it's a bit simpler than that where you make the mistake
once or twice and very quickly learn that "git push" means "push
what's in my repo", not "push only what's on my current branch". It's
a *very* easy lesson to learn if you get burnt and hardly requires
any adjustments to ones "mental model".
I personally would be in favour of changing the default because I
tend to work on a particular branch at a time and then want to push
*that* out -- generally I'm thinking about one general area or one
task at a time, and that means one branch at a time; I almost never
think along the lines of getting all my branches into shape at once
and then pushing them out in a batch. I think this is more likely to
be a common pattern, although obviously that remains speculation at
this point.
Changing the default would be great for people like me; by not having
to pass additional parameters to git-push I save some keystrokes. If
I ever want to push everything an "--all" switch would do the job.
But if people prefer to keep the old default then there'll
be .gitconfig for people like me. In any case I think more people
need to speak up on the topic so that we can find out what most
people really think about changing the default.
Cheers,
Wincent
^ permalink raw reply
* Re: WIP: asciidoc replacement
From: David Kastrup @ 2007-10-03 10:25 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Junio C Hamano, Johannes Schindelin, git, msysgit
In-Reply-To: <1D18C52E-BB96-49EC-97A9-F802D56CAFF5@wincent.com>
Wincent Colaiuta <win@wincent.com> writes:
> El 3/10/2007, a las 10:12, David Kastrup escribió:
>
>> What with output in print, HTML, info?
>
> Yes, that's still a problem...
>
>> Personally, I think it might make sense to just step away from the
>> AsciiDoc documentation to Docbook: plain text (without cutified
>> formatting control like in AsciiDoc) can be generated _from_ Docbook.
>
> Yes, but editing DocBook (XML) is relatively painful compared to
> editing plain text.
The problem is that we are not editing plain text, but Docbook source
masquerading as plain text.
> You either have to rely on a bloated XML- validating editor or
> instead ask your doc authors to manually write valid XML (and I
> totally agree with Terrence Parr that, "XML makes a lousy human
> interface "; see
> <http://www.ibm.com/developerworks/xml/library/x-sbxml.html> for his
> full take).
>
> I know that Linus has argued for AsciiDoc because the source *is*
> the plain text documentation and is therefore easily readable, but
> for me the real benefit lies in the fact that *because* the source
> is plain text it is easily edited (ie. that the source is easily
> *writeable*), and things like documentation patches are very neat
> with AsciiDoc.
But it is not all _all_ easily writeable the moment you try to do
something with _structural_ impact. In fact, it is pretty much
impossible for anybody except wizards to do that. And when the
wizards do it, they can't actually document what they have been doing
since that would mean cluttering the purported "plain text
documentation" with formatting comments.
Maybe it would help to rename *.txt to *.asciidoc and generate *.txt
in future. That would at least make it possible to document stuff in
the AsciiDoc source, and also would make it possible to add indexing
info and other stuff without cluttering up the plain text use case.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: WIP: asciidoc replacement
From: Wincent Colaiuta @ 2007-10-03 10:05 UTC (permalink / raw)
To: David Kastrup; +Cc: Junio C Hamano, Johannes Schindelin, git, msysgit
In-Reply-To: <85abr0y5ua.fsf@lola.goethe.zz>
El 3/10/2007, a las 10:12, David Kastrup escribió:
> What with output in print, HTML, info?
Yes, that's still a problem...
> Personally, I think it might make sense to just step away from the
> AsciiDoc documentation to Docbook: plain text (without cutified
> formatting control like in AsciiDoc) can be generated _from_ Docbook.
Yes, but editing DocBook (XML) is relatively painful compared to
editing plain text. You either have to rely on a bloated XML-
validating editor or instead ask your doc authors to manually write
valid XML (and I totally agree with Terrence Parr that, "XML makes a
lousy human interface
"; see <http://www.ibm.com/developerworks/xml/library/x-sbxml.html>
for his full take).
I know that Linus has argued for AsciiDoc because the source *is* the
plain text documentation and is therefore easily readable, but for me
the real benefit lies in the fact that *because* the source is plain
text it is easily edited (ie. that the source is easily *writeable*),
and things like documentation patches are very neat with AsciiDoc.
Cheers,
Wincent
^ permalink raw reply
* Re: merging .gitignore
From: Johan Herland @ 2007-10-03 9:28 UTC (permalink / raw)
To: git; +Cc: Andy Parkins, martin f krafft, Johannes Schindelin
In-Reply-To: <200710030923.22767.andyparkins@gmail.com>
On Wednesday 03 October 2007, Andy Parkins wrote:
> I am still having difficult seeing why you want to hide conflicts
> in .gitignore. It's just as possible to get and resolve conflicts in
> gitignore as in any other file.
Agreed. What about the following:
- No special merge rules for .gitignore
- Teach the .gitignore parser to ignore conflict markers (i.e. regard them
as comments)
This way, the user will have to merge .gitignore like any other file, but if
for some reason, the user is not able to do so (say, git needs to
consult .gitignore before the user has had a chance to resolve the
conflict), the fallback result will be similar to a union merge, which
shouldn't be extremely harmful in .gitignore's case.
I do not think we really want to create an auto-merge algorithm
for .gitignore, and then depend on this auto-merge algorithm to _always_
succeed with the _correct_ result and _no_ conflicts. These algorithms tend
to be extremely tricky to get right, especially for the "always correct"
requirement.
<rant>
Mercurial had a similar problem some months ago. They have their tag
definitions stored in a versioned file in the working tree (.hgtags IIRC).
But the repo tag state (i.e. Mercurial's opinion at any time as to _which_
tags are defined and _where_ they point) is not deduced from the copy in
your current working tree at all. (That would of course limit you to only
ba able to refer to tags defined earlier on the particular branch you're
currently on.) Instead the repo tag state was found by consulting
the "head-most" copy of the .hgtags file (for some definition
of "head-most" including non-obvious things like which branch has the most
recent commit, etc). The end result was that you could get some _really_
interesting behaviour depending on the order in which you commited totally
unrelated changes to two different branches which happened to have
different .hgtags files. (E.g.: Given two branches A, B, and - in .hgtags
on branch A - tag Foo is defined to point at rev X, and - in .hgtags on
branch B - Foo points at rev Y. Now, whether you got rev X or rev Y when
you checked out Foo, depended on which of branch A or branch B had the most
recent (totally unrelated, i.e. not even touching .hgtags) commit.)
I (and others) pointed out this bug on their ML, and instead of fixing the
braindeadness of allowing branched tag definitions in the repo in the first
place, they set about trying to create an auto-merge algorithm for deducing
the repo tag state from the various versions/branches of .hgtags found in
the repo. I didn't stick around for long enough to see how well this
auto-merge algorithm works (the misdesign of tags in Mercurial was one of
the reasons I started looking at git), but I would be surprised if
Mercurial today has a simple and straightforward way of deducing the repo
tag state that _always_ gives _correct_ (i.e. unsurprising) results, even
in the corner cases.
</rant>
Have fun! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ 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