* Re: [PATCH] Make the installation targets a little less chatty
From: Johannes Schindelin @ 2007-06-04 17:40 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, git, Shawn O. Pearce
In-Reply-To: <81b0412b0706040700s667afe5ap14a8343a9313ef60@mail.gmail.com>
Hi,
On Mon, 4 Jun 2007, Alex Riesen wrote:
> On 6/4/07, Junio C Hamano <gitster@pobox.com> wrote:
> > >
> > > Updated. BTW, where does "no $(call) in Makefile" came from?
> > > It could simplify the thing a lot
> >
> > Probably, but first let's make it "work right" while not
> > introducing new stuff.
> >
>
> Just looked for the reasons, which appear to be there:
> commit 39c015c556f285106931e0500f301de462b0e46e
> Author: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> Date: Sat Feb 18 12:40:22 2006 +0100
>
> Fixes for ancient versions of GNU make
>
> Some versions of GNU make do not understand $(call), and have problems to
> interpret rules like this:
>
> some_target: CFLAGS += -Dsome=defs
>
> [jc: simplified substitution a bit. ]
>
> Signed-off-by: Johannes E. Schindelin <Johannes.Schindelin@gmx.de>
> Signed-off-by: Junio C Hamano <junkio@cox.net>
>
> I trust Johannes to have such a make, never seen it myself, though.
Yes. I no longer have access to that machine, but it was an SGI machine
running IRIX, and I had no root access, and I had a quota.
That is when I worked towards getting rid of Python (making the use of it
optional at first), and working with incompatible or sufficiently non-GNU
programs like old make, different sed, etc.
At the time I was really annoyed with the situation, especially since it
was _easy_ to stay compatible with them. I have little sympathy with
making things just a little simpler for John R. Developer, and
substantially harder for a lot of users.
So, are you sure you want to force everybody who wants to compile Git to
use a recent GNU make?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Support environment variables in config file
From: Martin Waitz @ 2007-06-04 17:47 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Matthias Lederhofer, git
In-Reply-To: <Pine.LNX.4.64.0706041657210.4046@racer.site>
[-- Attachment #1: Type: text/plain, Size: 832 bytes --]
hoi :)
On Mon, Jun 04, 2007 at 04:57:35PM +0100, Johannes Schindelin wrote:
> I actually would like it more if the calling program did the interpolation
> itself.
That's another possibility, perhaps along the line of git_config_int.
> So, for example if you want a script to access whatever.my.url, and want
> to allow to interpolate any environment variable, why not
>
> url=$(eval $(git config whatever.my.url))
Well, complete shell syntax does too much: it also supports $() and
friends.
> I am just hesitant to change the existing behaviour, and possibly
> introduce weird breakages. (There could even be some unwanted env leakages
> in programs like gitweb...)
exactly.
So should we simply update semantics of config variables to not require
any environment variables?
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Add git-filter-branch
From: Johannes Schindelin @ 2007-06-04 17:55 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <46643F2D.7C896CBC@eudaptics.com>
Hi,
On Mon, 4 Jun 2007, Johannes Sixt wrote:
> Johannes Schindelin wrote:
> >
> > Hi,
> >
> > On Mon, 4 Jun 2007, Johannes Sixt wrote:
> > > I propose that you just get rid of the "seed" stance and don't fail if a
> > > commit cannot be mapped - just use it unchanged (don't forget to adjust
> > > the map() function, too).
> >
> > It is as much for debug reasons as for consistency, so I'd rather keep it.
> > One more safety valve for catching bugs.
> >
> > > Then you can get rid of -r and use -k to specify everything you want
> > > under "--not" in the rev-list.
> >
> > Actually, -r is quite useful. It means "start rewriting with this commit",
> > and saying "--not <commit>^" is _not_ the same when <commit> is a merge.
>
> But this makes only sense if you have a linear history. Consider this
> history, where you want to rewrite the commits that are only on branch
> 'next':
>
> --A--B--C--D--E--F--G--H <- master
> \ \ \ \ \ \ \ \
> X--o--o--o--o--o--o--o--o <- next
>
> How would you go about with the current calling convention?
Are you actually sure that this scenario makes sense? When is the last
time you wanted to filter a branch?
In any case, for such a degenerated test case I would rather try to limit
filtering in the filter expression. Remember: you don't have to change
_every_ commit.
Of course, if I am the only one defending this behaviour, I'll change it.
Ciao,
Dscho
^ permalink raw reply
* Re: Git Vs. Svn for a project which *must* distribute binaries too.
From: Thomas Glanzmann @ 2007-06-04 17:57 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Bryan Childs, git
In-Reply-To: <alpine.LFD.0.98.0706040857380.23741@woody.linux-foundation.org>
Hello,
> - instead of doing a "git pull" that merges the two branches (your work,
> and the work that happened by somebody else in the central repo while
> you did it), you *may* also just want to do a "git fetch" to fetch the
> changes from the central repo, and then do "git rebase origin" to
> linearize the work you did on _top_ of those central repo one (so that
> it no longer looks like a branch, and looks linear)
> In the "git rebase" case, you'll effectively merge your commits one at
> a time, and you may thus have to fix up *multiple* conflicts. So it's
> potentially more work, but it results in a simpler history if you want
> it.
Thank you a lot. I finally understood what "git rebase" is all about!
Thomas
^ permalink raw reply
* Re: [PATCH] Support environment variables in config file
From: Johannes Schindelin @ 2007-06-04 17:59 UTC (permalink / raw)
To: Martin Waitz; +Cc: Matthias Lederhofer, git
In-Reply-To: <20070604174719.GH16637@admingilde.org>
Hi,
On Mon, 4 Jun 2007, Martin Waitz wrote:
> On Mon, Jun 04, 2007 at 04:57:35PM +0100, Johannes Schindelin wrote:
> > I actually would like it more if the calling program did the
> > interpolation itself.
>
> That's another possibility, perhaps along the line of git_config_int.
Maybe...
> > So, for example if you want a script to access whatever.my.url, and
> > want to allow to interpolate any environment variable, why not
> >
> > url=$(eval $(git config whatever.my.url))
>
> Well, complete shell syntax does too much: it also supports $() and
> friends.
Good point.
> > I am just hesitant to change the existing behaviour, and possibly
> > introduce weird breakages. (There could even be some unwanted env
> > leakages in programs like gitweb...)
>
> exactly.
>
> So should we simply update semantics of config variables to not require
> any environment variables?
Well, actually there is a perfect example when you would want to do even
more than just expanding environment variables: aliases.
I'm happy to understand the config as a relatively versatile key/value
store, without much in the way of pre- or post-processing from git-config
or git_config().
But if there are a few callers of git_config() which want environment
variable interpolation, git_config_expand_envs() would be good.
Ciao,
Dscho
^ permalink raw reply
* Re: [ANNOUNCE] qgit new "smart browsing" feature
From: Andy Parkins @ 2007-06-04 19:03 UTC (permalink / raw)
To: git; +Cc: Marco Costalba, Pavel Roskin, Jan Hudec
In-Reply-To: <e5bfff550706040915v3689e8afwb3dffd5d4caf137a@mail.gmail.com>
On Monday 2007, June 04, Marco Costalba wrote:
> I have to say that I really like your idea!
Hurrah! See - even a blind golfer knocks one in eventually :-)
> Probably I will create a new branch called andy_gui where I'll
> implement your idea, while continue to refine the current approach.
Great stuff. If I get a moment, I'll try and chip in with some patches.
> As example one enanchment I would like to implement is to keep the
> labels normally hidden and show the top (bottom) one only when user
> scrolls to the top (bottom) boundary of the view so that we could
> resolve two issues: knowing when a scrolling action will cause a
> switch (i.e. only when the corresponding label is visible) and do not
> have the arrows when not needed.
That's certainly an improvement. I think in many cases both labels will
be visible - especially in log mode - because most log messages fit
completely inside one window.
> P.S: Your approach is simple and good, the only downside is the
> screen estate taken by the tab bar. But I agree it's absolutly not a
> biggie.
Yeah, that is a bit of a drawback. How about not putting the tabs on
the top or bottom, but on the left or right? In fact if you put them
on the right, they'd be almost exactly where your jump labels would be.
Maybe this is only better for me, but I tend to have more left-to-right
real estate available in the lower half of the screen, primarily
because the log messages tend to be limited to 80 columns, but the
revision list contains the ever-widening graph.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: How to use git-svn to clone from a mirror?
From: Johannes Schindelin @ 2007-06-04 18:08 UTC (permalink / raw)
To: Raja R Harinath; +Cc: git
In-Reply-To: <85myzfsqji.fsf@blr-RHarinath.blr.novell.com>
Hi,
On Mon, 4 Jun 2007, Raja R Harinath wrote:
> David Kastrup <dak@gnu.org> writes:
>
> > I have used something like
> >
> > git-svn clone -T trunk -b branches -t tags file:///tmp/rsync-mirror
> >
> > to clone an rsync mirror of an SVN repository. Now I want to have
> > fetch revert to pulling from the upstream repository in future.
> > However, if I change the respective line in .git/config to
> > svn://the.svn.link/whatever, git-rebase will fetch the right updates,
> > but then says that it can't work with the objects in the git
> > repository.
> >
> > Changing the config back will make git-rebase -l work.
> >
> > So what would be the right procedure to shift the SVN source from an
> > rsync mirror to the original, without git-svn breaking?
>
> I think you'll have to
>
> -------------8<------------
> # remove stored revision db, since we're going to change all the commit ids
> rm .git/svn/git-svn/.rev_db.*
>
> # rewrite git-svn-id: lines
> cg-admin-rewritehist \
> --msg-filter \
> 'sed "s,file:///tmp/rsync-mirror,svn://the.svn.link/whatever,"'
>
> # recreate new revision db, and fetch updates, if any
> git-svn rebase
> -------------8<------------
<shameless plug>
Or you use the just-rewritten version of it, git-filter-branch.
</shameless>
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC PATCH] Add git quick reference
From: Jonas Fonseca @ 2007-06-04 18:45 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: git
In-Reply-To: <20070603171547.GA1965@fieldses.org>
J. Bruce Fields <bfields@fieldses.org> wrote Sun, Jun 03, 2007:
> On Sat, Jun 02, 2007 at 08:24:23PM +0200, Jonas Fonseca wrote:
> > It attempts to list some of the most commonly used commands, which should
> > give new users an idea of how to get started.
> >
> > Available both as a manpage (generated via a script) and HTML page.
>
> We have a "git quick start" here:
>
> http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#git-quick-start
>
> and there's one on the wiki:
>
> http://git.or.cz/gitwiki/QuickStart
>
> I think the one in the manual tries to follow the organization of the
> manual more closely.
I like the manual version best. However, it is not as "visually" clean
and simple as I would like, but perhaps this sort of "use case" approach
is better.
> I haven't tried to compare those two recently, or to compare yours to
> either of them. If you could compare and suggest any improvements,
> that'd be helpful.
I will see what I can do when I get the time and courage. :)
> I like your name better ("quick reference" as opposed to "quick start").
Yes, "quick start" suggest (at least to me) that it is a tutorial and it
seems far from that.
> Having it as a man page may be a good idea too. I'd like to keep a copy
> in the manual as well, though, so we'd have to include from some common
> file.
The main idea was to have the reference in a printable format similar to
svn-ref. But the man page was easy to do, although it might not be
something that users would stumble upon.
--
Jonas Fonseca
^ permalink raw reply
* Re: [PATCH 0/6] Refactor the tag object
From: Junio C Hamano @ 2007-06-04 20:32 UTC (permalink / raw)
To: Johan Herland; +Cc: git
In-Reply-To: <200706040251.52613.johan@herland.net>
Johan, I gave only a cursory look at the series so far (that is,
I looked at your log message and had a very quick pass over the
code to see what the basic idea is and if it is sound, without
really reading/reviewing the code). It all looks good.
^ permalink raw reply
* Re: [PATCH] Show html help with git-help --html
From: Junio C Hamano @ 2007-06-04 20:42 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Junio C Hamano, git
In-Reply-To: <fcaeb9bf0706040629k489d4818sa291725cbbeead79@mail.gmail.com>
"Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:
> On 6/4/07, Junio C Hamano <gitster@pobox.com> wrote:
>> > diff --git a/Documentation/config.txt b/Documentation/config.txt
>> > index 3d8f03d..2ec8545 100644
>> > --- a/Documentation/config.txt
>> > +++ b/Documentation/config.txt
>> > @@ -261,6 +261,18 @@ core.excludeFile::
>> > ...
>> > +core.htmlprogram::
>> > + Specify the program used to open html help files when 'git-help'
>> > + is called with option --html or core.help is other than 'man'.
>> > + By default, xdg-open will be used.
>>
>> Is the program's calling convention something that needs to be
>> customizable for this to be useful?
>
> At first I thought xdg-open would be flexible enough for most Linux
> systems because it will choose the best browser you have. But I now
> recall that Git does not only run on Linux. Will make it a parameter
> in config.mak.in
Actually that was not what I meant. I thought we might need to
support something like:
core.htmlprogram = grand-unified-help %b
for a program that knows where in the system the distribution
keeps help HTML files, and add prefix (/usr/share/html-help/,
perhaps) and suffix (obviously, .html) to the basename of the
command (e.g. "grand-unified-help git-rebase" ends up running
"lynx file:///usr/share/html-help/git-rebase.html"), or perhaps
core.htmlprogram = firefox /usr/share/html-help/%f
and we substitute '%f' with "git-rebase.html".
>> ...
>> > + if (prefixcmp(git_cmd, "git"))
>> > + strcat(p,"git-");
>> > + strcat(p,git_cmd);
>> > + strcat(p,".html");
>> > +
>> > + ret = system(p);
>>
>> This is sloppy in the presense of potentially unsafe characters...
>
> I personally think users will not shoot themselves with "git help
> --html ';rm -rf'" but again scripts can. Thank you for pointing out.
> Will add check for file existence before calling system().
File existence? I am not sure what you mean by that, sorry.
^ permalink raw reply
* Re: Git Vs. Svn for a project which *must* distribute binaries too.
From: Linus Torvalds @ 2007-06-04 20:45 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: Bryan Childs, git
In-Reply-To: <20070604175751.GL19935@cip.informatik.uni-erlangen.de>
On Mon, 4 Jun 2007, Thomas Glanzmann wrote:
>
> > - instead of doing a "git pull" that merges the two branches (your work,
> > and the work that happened by somebody else in the central repo while
> > you did it), you *may* also just want to do a "git fetch" to fetch the
> > changes from the central repo, and then do "git rebase origin" to
> > linearize the work you did on _top_ of those central repo one (so that
> > it no longer looks like a branch, and looks linear)
> >
> > In the "git rebase" case, you'll effectively merge your commits one at
> > a time, and you may thus have to fix up *multiple* conflicts. So it's
> > potentially more work, but it results in a simpler history if you want
> > it.
>
> Thank you a lot. I finally understood what "git rebase" is all about!
I'd like to point out some more upsides and downsides of "git rebase".
Downsides:
- you're rewriting history, so you MUST NOT have made your pre-rebase
changes available publicly anywhere else (or you are in a world of pain
with duplicate history and tons of confusion)
- you can only rebase "simple" commits. If you don't just have a linear
history of your own commits, but have merged from others, rebasing
isn't a sane alternative (yeah, we could make it do something half-way
sane, but really, it's not worth even contemplating)
Upsides:
- while there may be more conflicts you have to sort out, they may be
individually simpler, so you *might* actually prefer to do it that
way.
- if the reason for the conflicts is that upstream did some nice cleanup
in the same area, and you decide that you would actually want to re-do
your development based on that nice cleanup, then "git rebase" can
actually be used as a way to help you do exactly that. IOW, you can
take _advantage_ of the conflicts as a way to re-apply the patches but
also then fix them up by hand to work in the new (better) world order.
And finally, the upside that is probably the most common case for using
"git rebase", and has nothing to do with resolving conflicts before
pushing them out with "git push":
- if you actually want to send your changes upstream as emailed *patches*
rather than by pushing them out (or asking somebody else to pull them),
rebasing is an excellent way to keep the set of patches "fresh" on top
of the current development tree.
People who send their patches out as emails are also unlikely to have
the downsides (ie they normally send them as patches exactly *because*
they don't want to make their git trees public, and they probably just
have a small set of simple patches in their tree anyway)
So I have to say, I'm still very ambivalent about rebasing. It's
definitely a very useful thing to do, but at the same time I think "git
pull" in many ways is often the more honest and correct way to do things.
Linus
^ permalink raw reply
* [PATCH] Fix deletion and move of a hidden patch (gna bug #9244).
From: Yann Dirson @ 2007-06-04 21:14 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
We must unhide a patch before we delete it, or we get an exception
while trying to unhide a non-existent patch.
Similarly, when renaming a hidden patch, we must take care of hiding
an unhiding at the right moment.
Both problems introduced in commit
841c7b2a6b015e3ab3331713cf10caf7a4fd0b49 when first indroducing patch
hiding.
Signed-off-by: Yann Dirson <ydirson@altern.org>
---
stgit/stack.py | 13 +++++++++----
t/t1600-delete-one.sh | 13 +++++++++++--
2 files changed, 20 insertions(+), 6 deletions(-)
diff --git a/stgit/stack.py b/stgit/stack.py
index 7a06458..ed54671 100644
--- a/stgit/stack.py
+++ b/stgit/stack.py
@@ -894,6 +894,9 @@ class Series(StgitObject):
# save the commit id to a trash file
write_string(os.path.join(self.__trash_dir, name), patch.get_top())
+ if self.patch_hidden(name):
+ self.unhide_patch(name)
+
patch.delete()
unapplied = self.get_unapplied()
@@ -902,9 +905,6 @@ class Series(StgitObject):
f.writelines([line + '\n' for line in unapplied])
f.close()
- if self.patch_hidden(name):
- self.unhide_patch(name)
-
def forward_patches(self, names):
"""Try to fast-forward an array of patches.
@@ -1168,7 +1168,9 @@ class Series(StgitObject):
if self.patch_hidden(oldname):
self.unhide_patch(oldname)
- self.hide_patch(newname)
+ was_hidden=True
+ else:
+ was_hidden=False
if oldname in unapplied:
Patch(oldname, self.__patch_dir, self.__refs_dir).rename(newname)
@@ -1188,6 +1190,9 @@ class Series(StgitObject):
else:
raise StackException, 'Unknown patch "%s"' % oldname
+ if was_hidden:
+ self.hide_patch(newname)
+
def log_patch(self, patch, message):
"""Generate a log commit for a patch
"""
diff --git a/t/t1600-delete-one.sh b/t/t1600-delete-one.sh
index df03d79..d59d4ba 100755
--- a/t/t1600-delete-one.sh
+++ b/t/t1600-delete-one.sh
@@ -82,6 +82,15 @@ test_expect_success \
'
test_expect_success \
+ 'Hide the topmost patch and try to delete it' \
+ '
+ [ $(stg applied | wc -l) -eq 2 ] &&
+ stg hide bar &&
+ stg delete bar &&
+ [ $(stg applied | wc -l) -eq 1 ]
+ '
+
+test_expect_success \
'Create another branch, and put one patch in each branch' \
'
stg branch --create br &&
@@ -99,10 +108,10 @@ test_expect_success \
test_expect_success \
'Delete a patch in another branch' \
'
- [ $(stg applied | wc -l) -eq 3 ] &&
+ [ $(stg applied | wc -l) -eq 2 ] &&
[ $(stg applied -b br | wc -l) -eq 1 ] &&
stg delete -b br baz &&
- [ $(stg applied | wc -l) -eq 3 ] &&
+ [ $(stg applied | wc -l) -eq 2 ] &&
[ $(stg applied -b br | wc -l) -eq 0 ]
'
^ permalink raw reply related
* Re: Improved git-gui blame viewer
From: Matthijs Melchior @ 2007-06-04 21:26 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20070604060720.GF4507@spearce.org>
Shawn O. Pearce wrote:
> Matthijs Melchior <mmelchior@xs4all.nl> wrote:
....
>
>> Something I want for the normal window, in the Staged and Unstaged
>> file lists, high-lite the last entry selected so it becomes easy to
>> click on the next one and I can see more clearly what is displayed
>> in the bottom area.
>
> I'm not sure I understand what you are looking for here. Right now
> git-gui should be inverting the foreground/background colors on
> the file that is "selected" (shown in the lower diff view pane).
> So the background should be black, and the foreground white.
> Is this not happening? Or are you looking for something else?
>
No, I am not looking for something else...., the inverting you describe
does not happen on my machine....
I am now running Debian git-core 1.5.2.1-1 with 'make install' done
in the origin/pu branch of git-gui.
'About git-gui' now says:
git-gui version 0.7.2.58-gf9e9
git version 1.5.2.1
Tcl/Tk version 8.4.12
If you explain where this inverting is taking place, I can do some
experiments to find out more [use gray background i.s.o. inverting...]
Maybe it has something to do with Desktop themes, I use the standard
Gnome theme.
Thanks,
Matthijs Melchior.
^ permalink raw reply
* Re: Git Vs. Svn for a project which *must* distribute binaries too.
From: Olivier Galibert @ 2007-06-04 21:21 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Thomas Glanzmann, Bryan Childs, git
In-Reply-To: <alpine.LFD.0.98.0706041336440.23741@woody.linux-foundation.org>
On Mon, Jun 04, 2007 at 01:45:26PM -0700, Linus Torvalds wrote:
> I'd like to point out some more upsides and downsides of "git rebase".
>
> Downsides:
>
> - you're rewriting history, so you MUST NOT have made your pre-rebase
> changes available publicly anywhere else (or you are in a world of pain
> with duplicate history and tons of confusion)
Wouldn't it be possible to register the rebase somewhere (weak parent?
some kind of note not influencing the sha1 ?) that pull/merge could
follow? Rebases and cherry-picking are a special kind of merge, so
maybe it can be handled like one where it counts...
OG.
^ permalink raw reply
* Re: Git Vs. Svn for a project which *must* distribute binaries too.
From: Linus Torvalds @ 2007-06-04 21:33 UTC (permalink / raw)
To: Olivier Galibert; +Cc: Thomas Glanzmann, Bryan Childs, git
In-Reply-To: <20070604212121.GA31852@dspnet.fr.eu.org>
On Mon, 4 Jun 2007, Olivier Galibert wrote:
> On Mon, Jun 04, 2007 at 01:45:26PM -0700, Linus Torvalds wrote:
> > I'd like to point out some more upsides and downsides of "git rebase".
> >
> > Downsides:
> >
> > - you're rewriting history, so you MUST NOT have made your pre-rebase
> > changes available publicly anywhere else (or you are in a world of pain
> > with duplicate history and tons of confusion)
>
> Wouldn't it be possible to register the rebase somewhere (weak parent?
> some kind of note not influencing the sha1 ?) that pull/merge could
> follow? Rebases and cherry-picking are a special kind of merge, so
> maybe it can be handled like one where it counts...
Well, it's not like duplicate history is a disaster from a *technical*
angle. It might be a small space-waster etc, but that's really not the
real issue.
The problem with duplicate history is that it just makes things much
harder to look at. IOW, it's *messy*. So the "tons of confusion" part is
basically purely about humans, not about git itself. Git won't really
care, and there's no reason to "handle" it specially in that sense.
So I would strongly discourage people from ever making rebased history
available, but that's not because of any particular git technical issues
as just because of it being a good way to confuse all the _humans_
involved.
(That said, gits own 'pu' branch ends up jumping around, and it hasn't
caused all that much confusion, so maybe I'm overstating even that human
confusion)
Linus
^ permalink raw reply
* Re: [RFC] git integrated bugtracking
From: Yann Dirson @ 2007-06-04 22:03 UTC (permalink / raw)
To: Johan Herland, git, Michael Poole
In-Reply-To: <20070603151921.GB30347@artemis>
Another aspect that I have not seen discussed yet is the handling of
testcases that expose a bug, and which are usually integrated as
non-reg tests afterwards.
If we're going the way of using git-note's, we can easily link the
commit which adds the testcase to the non-reg testsuite.
But we could be interested in running the testcase against an
arbitrary commit, thus allowing some sort of automated bisect (modulo
applicability of the testcase to other commits, which may cause false
negatives, but also false positives, and thus may need to be
hand-driven or at least hand-reviewed).
For this, however, would it be sufficient to have the testcase
committed somewhere in the history tree ? Our hypothetic automatic
bisect tool could cherry-pick that commit and run the testcase, but at
would place an arbitrary restriction of "one testcase per commit",
which would probably a bad idea.
And having the annotation point to the blob does not seem a good idea
either, at least because currently in git tools we have test scripts
that excercise several testcases each.
Even an annotation to both a commit and a blob changed by that commit
would not be sufficiently accurate, when several testcases are added
to the same script in a single commit.
Another options would be to embed the testcase in an annotation: I
can't really see that being used, since that would duplicate the
testcase. That makes me wonder whether it would not be required to
have testcases described in seperate files ?
Best regards,
--
Yann.
^ permalink raw reply
* Re: StGIT: stgitformatversion vs. stgit.formatversion
From: Catalin Marinas @ 2007-06-04 22:12 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Yann Dirson, GIT list
In-Reply-To: <20070603121718.GA6507@diana.vm.bytemark.co.uk>
On 03/06/07, Karl Hasselström <kha@treskal.com> wrote:
> On 2007-06-02 21:16:41 +0200, Yann Dirson wrote:
>
> > What about using branch.*.stgit.formatversion to store the version,
> > to be consistent with other stgit-specific per-branch settings ?
I agree as well.
> Good idea. But we should probably fall back to stgitformatversion (or
> better, upgrade from it) to be nice to those running Catalin's master.
It could, indeed, fall back to stgitformatversion and upgrade from it.
Anyway, I'm not sure there are that many running the master branch but
this would be needed for us as well.
> It happens a bit too often that we find problems with patches only
> after Catalin has published them on "master". (At least that seems to
> be the case with patches coming from me!) Maybe a "pu" branch
> (maintained either by Catalin or someone else) would be a good way to
> smoke them out before they're written in stone and distributed to lots
> of people.
Well, I consider "master" to be a development branch anyway. It would
be useful to get an idea of how many are using this branch (people not
following the GIT list are probably using the stable releases anyway).
A "pu" branch would make sense for more experimental stuff, like the
DAG patches.
> If the stgitformatversion patch had been on such a branch, we could
> just have edited it and not have to worry about upgrading old configs
> (aside from posting a mail on how to upgrade manually).
But now I have plenty of branches in my Linux tree already, so I
wouldn't do it manually. We already have checks for the repository
version, adding this would probably only be 2-3 lines.
--
Catalin
^ permalink raw reply
* Re: [PATCH 4/4] Add new --diff-opts/-O flag to diff- and status-related commands.
From: Catalin Marinas @ 2007-06-04 22:15 UTC (permalink / raw)
To: Yann Dirson; +Cc: git
In-Reply-To: <20070531223438.6005.76115.stgit@gandelf.nowhere.earth>
On 31/05/07, Yann Dirson <ydirson@altern.org> wrote:
> This new flag allows to pass arbitrary flags to the git-diff calls
> underlying several StGIT commands. It can be used to pass flags
> affecting both diff- and status-generating commands (eg. -M or -C), or
> flags only affecting diff-generating ones (eg. --color, --binary).
>
> It supercedes --binary for commands where it was allowed,
> '-O --binary' is now available for the same functionality.
BTW, should we add --binary by default to export and mail? Do you see
any problem with this?
Another idea would be to add support for a [stgit "options"] section
with entries like "mail = -O --binary".
--
Catalin
^ permalink raw reply
* Re: [RFC] git integrated bugtracking
From: Pierre Habouzit @ 2007-06-04 22:25 UTC (permalink / raw)
To: Yann Dirson; +Cc: Johan Herland, git, Michael Poole
In-Reply-To: <20070604220308.GJ6992@nan92-1-81-57-214-146.fbx.proxad.net>
[-- Attachment #1: Type: text/plain, Size: 994 bytes --]
On Tue, Jun 05, 2007 at 12:03:08AM +0200, Yann Dirson wrote:
> Another aspect that I have not seen discussed yet is the handling of
> testcases that expose a bug, and which are usually integrated as
> non-reg tests afterwards.
Well IMHO testcases are to be dealt with from the build sytem, and
versionned in the SCM. You may want to have some kind of helper doing
the bisect automatically for you (though, speaking of experience, it's
not always _that_ simple because of broken commits that do not build
e.g.) But I hardly see how it can be realted to a BTS anyways. I mean,
bugs will likely have test cases to exhibit the bug, but those should be
put in the test-case part of the repository. I mean well, maybe there is
fancy things to do, but I don't think it should be the role of a BTS at
all.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Git Vs. Svn for a project which *must* distribute binaries too.
From: Martin Langhoff @ 2007-06-04 22:29 UTC (permalink / raw)
To: Bryan Childs; +Cc: Linus Torvalds, git
In-Reply-To: <5971b1ba0706040838nc9ea7c7h54a57d4235d53bcf@mail.gmail.com>
On 6/5/07, Bryan Childs <godeater@gmail.com> wrote:
> Oh lord no - I never meant to imply that we'd be checking those
> binaries in, I just meant to hi-light that we need a central
> repository to build those binaries from - otherwise we'd end up with a
If your infrastructure to build the binaries is automated, you can
easily script the build for new incoming commits. The output of
git-describe is really useful for this if you are going to name your
builds `git describe`-<arch>.tar.gz.
OTOH, commit is different from push (vs SVN where both are one op),
and that means that when using git you can present a large change as a
better-explained patch-series. That's actually a good practice for new
development, and it might not make sense to have literally
one-build-per-commit.
Maybe I'd enable auto-builds for maintenance/bugfixes branches, and on
other (experimental/devel) branches only auto-build commits selected
explicitly (tagged?).
cheers,
martin
^ permalink raw reply
* Re: Git Vs. Svn for a project which *must* distribute binaries too.
From: Joel Becker @ 2007-06-04 22:30 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Olivier Galibert, Thomas Glanzmann, Bryan Childs, git
In-Reply-To: <alpine.LFD.0.98.0706041429380.23741@woody.linux-foundation.org>
On Mon, Jun 04, 2007 at 02:33:18PM -0700, Linus Torvalds wrote:
> (That said, gits own 'pu' branch ends up jumping around, and it hasn't
> caused all that much confusion, so maybe I'm overstating even that human
> confusion)
It survives because it is well-known. Everyone expects it to
break. ocfs2 has an "ALL" branch that is everything we have working,
sort of a "test this bleeding edge" thing. It gets rebased all the
time, and everyone knows that they can't trust it to update linearly.
Other developers have similar things in their repositories.
Joel
--
"What no boss of a programmer can ever understand is that a programmer
is working when he's staring out of the window"
- With apologies to Burton Rascoe
Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127
^ permalink raw reply
* Re: [StGIT RFC PATCH 0/2] Fixing the rebase safeguard
From: Catalin Marinas @ 2007-06-04 22:41 UTC (permalink / raw)
To: Yann Dirson; +Cc: git
In-Reply-To: <20070603133006.1681.1742.stgit@gandelf.nowhere.earth>
On 03/06/07, Yann Dirson <ydirson@altern.org> wrote:
> This is an attempt at using a reachability test to replace the use of
> orig-base, to decide when it is safe to accept a rebase.
[...]
> - using ORIG_HEAD, but then, how do we decide when it is valid to do
> so ?
I think using the ORIG_HEAD was the initial behaviour of StGIT. I
didn't have any problems as I am only following one tree (Linus'
mainline kernel) but other users might have different scenarios.
--
Catalin
^ permalink raw reply
* Re: [PATCH] Show html help with git-help --html
From: Nguyen Thai Ngoc Duy @ 2007-06-04 23:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Junio C Hamano, git
In-Reply-To: <7vvee3ih8s.fsf@assigned-by-dhcp.cox.net>
On 6/4/07, Junio C Hamano <junkio@cox.net> wrote:
> "Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:
>
> > On 6/4/07, Junio C Hamano <gitster@pobox.com> wrote:
> >> > diff --git a/Documentation/config.txt b/Documentation/config.txt
> >> > index 3d8f03d..2ec8545 100644
> >> > --- a/Documentation/config.txt
> >> > +++ b/Documentation/config.txt
> >> > @@ -261,6 +261,18 @@ core.excludeFile::
> >> > ...
> >> > +core.htmlprogram::
> >> > + Specify the program used to open html help files when 'git-help'
> >> > + is called with option --html or core.help is other than 'man'.
> >> > + By default, xdg-open will be used.
> >>
> >> Is the program's calling convention something that needs to be
> >> customizable for this to be useful?
> >
> > At first I thought xdg-open would be flexible enough for most Linux
> > systems because it will choose the best browser you have. But I now
> > recall that Git does not only run on Linux. Will make it a parameter
> > in config.mak.in
>
> Actually that was not what I meant. I thought we might need to
> support something like:
>
> core.htmlprogram = grand-unified-help %b
>
> for a program that knows where in the system the distribution
> keeps help HTML files, and add prefix (/usr/share/html-help/,
> perhaps) and suffix (obviously, .html) to the basename of the
> command (e.g. "grand-unified-help git-rebase" ends up running
> "lynx file:///usr/share/html-help/git-rebase.html"), or perhaps
>
> core.htmlprogram = firefox /usr/share/html-help/%f
>
> and we substitute '%f' with "git-rebase.html".
Ok. Now I get it.
>
> >> ...
> >> > + if (prefixcmp(git_cmd, "git"))
> >> > + strcat(p,"git-");
> >> > + strcat(p,git_cmd);
> >> > + strcat(p,".html");
> >> > +
> >> > + ret = system(p);
> >>
> >> This is sloppy in the presense of potentially unsafe characters...
> >
> > I personally think users will not shoot themselves with "git help
> > --html ';rm -rf'" but again scripts can. Thank you for pointing out.
> > Will add check for file existence before calling system().
>
> File existence? I am not sure what you mean by that, sorry.
Something like this on top of the last patch.
diff --git a/help.c b/help.c
index e3e705b..6f5c340 100644
--- a/help.c
+++ b/help.c
@@ -191,7 +191,8 @@ static void show_html_page(const char *git_cmd)
{
const char *html_dir;
int i,len,ret;
- char *p;
+ char *p,*pathname;
+ struct stat html_stat;
html_dir = HTML_DIR;
if (!html_help_program)
@@ -203,13 +204,19 @@ static void show_html_page(const char *git_cmd)
strcpy(p, html_help_program);
strcat(p," ");
+ pathname = p + strlen(p);
strcat(p,html_dir);
if (prefixcmp(git_cmd, "git"))
strcat(p,"git-");
strcat(p,git_cmd);
strcat(p,".html");
- ret = system(p);
+ if (!stat(pathname, &html_stat))
+ ret = system(p);
+ else {
+ error("%s not found",pathname);
+ ret = -1;
+ }
/* fallback to man pages */
if (show_html_help > 1 && (ret == -1 || ret > 0))
--
Duy
^ permalink raw reply related
* Re: Git Vs. Svn for a project which *must* distribute binaries too.
From: Jakub Narebski @ 2007-06-04 23:46 UTC (permalink / raw)
To: git
In-Reply-To: <5971b1ba0706040448i6e166031od1212192a549c4a9@mail.gmail.com>
Bryan Childs wrote:
> 3) With a central repository, for which we have a limited number of
> individuals having commit access, it's easy for us to automate a build
> based on each commit the repository receives.
Check out contrib/continuous/ scripts in git repository: you would have
to enable it only on one machine, of course.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Git Vs. Svn for a project which *must* distribute binaries too.
From: Daniel Barkalow @ 2007-06-04 23:48 UTC (permalink / raw)
To: Bryan Childs; +Cc: Linus Torvalds, git
In-Reply-To: <5971b1ba0706040838nc9ea7c7h54a57d4235d53bcf@mail.gmail.com>
On Mon, 4 Jun 2007, Bryan Childs wrote:
> On 6/4/07, Linus Torvalds < [send email to
> torvalds@linux-foundation.org via gmail]
> torvalds@linux-foundation.org> wrote:
> > So I *hope* that you want to just have automated build machinery that
> > builds the binaries to a *separate* location? You could use git to archive
> > them, and you can obviously (and easily) name the resulting binary blobs
> > by the versions in the source tree, but I'm just saying that trying to
> > track the binaries from within the same git repository as the source code
> > is less than optimal.
>
> Oh lord no - I never meant to imply that we'd be checking those
> binaries in, I just meant to hi-light that we need a central
> repository to build those binaries from - otherwise we'd end up with a
> selection of binaries for our users to download which contain a bunch
> of different features if they were built from a combination of
> repositories. I know you think everyone else is a moron, but we're not
> quite dumb enough to think maintaining binaries in a repository is a
> good idea :)
Actually, I've been playing with using git's data-distribution mechanism
to distribute generated binaries. You can do tags for arbitrary binary
content (not in a tree or commit), and, if you have some way of finding
the right tag name, you can fetch that and extract it.
I came up with this at my job when we were trying to decide what to do
with firmware images that we'd shipped, so that we'd be able to examine
them again even if we lose the compiler version we used at the time. We
needed an immutable data store with a mapping of tags to objects, and I
realized that we already had something with these exact characteristics.
-Daniel
*This .sig left intentionally blank*
^ 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