* Re: [RFC GSoC 2009: git-submodule for multiple, active developers on active trees]
From: P Baker @ 2009-03-31 23:49 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Shawn O. Pearce, git
In-Reply-To: <alpine.DEB.1.00.0904010058490.6616@intel-tinevez-2-302>
I'll paraphrase to see if I understand your points:
*Moving objects from submodule .git directories into the base .git/
directory would protect the submodules and is a good idea.
*Moving to a .git/ file from .gitmodules should be taken off of the
goal list (I went back and read this thread:
http://thread.gmane.org/gmane.comp.version-control.git/78605; seemed
to clear things up).
*git submodule recurse would be a good option (not as a default), if
the remaining issues are resolved.
*It would be a good idea for git submodule to work with foreign VCS,
through Daniel's patches.
I appreciate the guidance, it's helping me to see that some of this
work has already been done, it needs to be finished and pushed into a
public release. As an intense user of submodules, what does it do
poorly/not do for your needs?
Thanks,
Phillip Baker
On Tue, Mar 31, 2009 at 7:05 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Tue, 31 Mar 2009, P Baker wrote:
>
>> On Tue, Mar 31, 2009 at 11:57 AM, Johannes Schindelin
>> <Johannes.Schindelin@gmx.de> wrote:
>>
>> >> *move objects of submodules into base .git/ directory
>> >> **This would, as I understand it: protect submodules from being
>> >> overwritten and changes lost when switching between branches of the
>> >> superproject that might or might not contain the submodules and
>> >> centralize their management into one location. The added benefits of
>> >> fully using git's ability to branch and merge submodules makes it
>> >> worth adding some complexity within the .git directory.
>> >
>> > The main problem with renaming/deleting is not the repository of the
>> > submodule, but the working directoy.
>> >
>>
>> My understanding is that since the submodule objects (history) is
>> stored in a .git directory in the subdirectory where the submodule is
>> located, removing that subdirectory during checkout of a branch that
>> does not include that submodule eliminates the .git directory as well.
>> Moving the objects from the submodule's .git directory to the base
>> .git directory would seem to alleviate this problem.
>
> My point was more about "you cannot just remove the subdirectory, or you
> _will_ lose data".
>
>> >> *use .git instead of .gitmodules
>> >> **I actually don't know why this was included with the project
>> >> description, I searched for an explanation of the desired name change
>> >> on the mailing list and in commit messages, but came up with nothing.
>> >
>> > AFAICT somebody thought that the information about the locations of the
>> > submodules should be in .git/ rather than in the working directory. But
>> > of course, that is wrong: you want it to be tracked.
>>
>> So, in looking back through the archives of the mailing list there
>> seems to be some disagreement between using .gitmodules and
>> .git/config to track submodules.
>
> No. .gitmodules has the default information, and "git submodule init"
> brings that into .git/config, to be overridden by the user if she so
> likes.
>
>> >> *git submodule update --init should initialize nested levels of submodules
>> >> **As an ease of use command, either an additional flag to recurse can
>> >> be added, or it can act by default. As a requested feature on the
>> >> mailing list, this is worth implementing.
>> >
>> > I thought there was a patch to support "git submodule recurse"? That
>> > would be rather less limited than yet another option to submodule update.
>>
>> There is a git submodule foreach command, but it doesn't look like the
>> patch for git submodule recurse
>> (http://marc.info/?l=git&m=120997867213008&w=2) has been incorporated
>> into a public release.
>>
>> That is one route, on the other hand, the default action is also open
>> to question. When I update a submodule, I would probably expect that
>> anything it depends on is also updated. The default action probably
>> should be recursive.
>
> No. Not at all. At least in my usage, submodules are mostly optional.
> IOW I have ways in my projects to cope with the absence of a checkout.
>
>> >> *ability to update submodule pulled from svn repo
>> >> **One workaround is to clone it as local copy using git-svn and then
>> >> import that local clone as a submodule; clearly a clunky solution.
>> >> There are many requests for this feature (see
>> >> http://panthersoftware.com/articles/view/4/git-svn-dcommit-workaround-for-git-submodules
>> >> for a typical example), and it makes sense integrating git-submodule
>> >> with git-svn would expand submodule's usefulness.
>> >
>> > I do not think that this would be good. Both "git svn" and "git
>> > submodule" are rather complex by now, and mixing them would only
>> > complicate code.
>>
>> Hm, point well taken, but it would seem to have enormous benefit for a
>> lot of people. I can move it down the priority list, but I'd like to
>> include it in the proposal - complexity alone isn't a good reason to
>> avoid something.
>
> Complexity is often a good sign of bad design.
>
> In this case, I want to point out that there has been a better design
> already:
>
> http://thread.gmane.org/gmane.comp.version-control.git/114545
>
> (Unfortunately, Daniel decided to post the follow-up patches in different
> threads; that will make it hard for you to find them.)
>
> Ciao,
> Dscho
>
>
^ permalink raw reply
* [PATCH] git-gui (Win): make starting via "Git GUI Here" on .git/ possible
From: Markus Heidelberg @ 2009-03-31 23:55 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, msysgit
This works around git-gui's error message
Cannot use funny .git directory: .
when started from the .git/ directory, which is useful in repositories
without any directories for the right click.
Now git-gui can be started via Windows Explorer shell extension (Git GUI
Here) from the .git/ directory.
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
---
windows/git-gui.sh | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/windows/git-gui.sh b/windows/git-gui.sh
index 53c3a94..66bbb2f 100644
--- a/windows/git-gui.sh
+++ b/windows/git-gui.sh
@@ -3,7 +3,12 @@
exec wish "$0" -- "$@"
if { $argc >=2 && [lindex $argv 0] == "--working-dir" } {
- cd [lindex $argv 1]
+ set workdir [lindex $argv 1]
+ cd $workdir
+ if {[lindex [file split $workdir] end] eq {.git}} {
+ # Workaround for Explorer right click "Git GUI Here" on .git/
+ cd ..
+ }
set argv [lrange $argv 2 end]
incr argc -2
}
--
1.6.2.1.428.g41b20c
^ permalink raw reply related
* [PATCH] git-gui (Win): make "Explore Working Copy" more robust
From: Markus Heidelberg @ 2009-03-31 23:55 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, msysgit
Starting the Explorer from the git-gui menu "Explore Working Copy"
didn't work, when git-gui was started via Windows Explorer shell
extension (Git GUI Here) from a directory within the project.
The Explorer raised an error message like this:
Path "C:/somedir/worktree" is not available or not a directory
It worked when started from the project directory itself, because then
the path argument for the Explorer was just '.' (current directory)
without any problematic forward slashes.
To make it work, convert the path given as argument to explorer.exe to
its native format with backslashes.
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
---
Now this is the real location of the problem in contrast of the
workaround attempt from 2 days before.
I've also tested this change with xdg-open.
git-gui.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-gui.sh b/git-gui.sh
index b3aa732..712fe27 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -1924,7 +1924,7 @@ proc do_explore {} {
# freedesktop.org-conforming system is our best shot
set explorer "xdg-open"
}
- eval exec $explorer [file dirname [gitdir]] &
+ eval exec $explorer [list [file nativename [file dirname [gitdir]]]] &
}
set is_quitting 0
--
1.6.2.1.428.g41b20c
^ permalink raw reply related
* Re: [PATCH] Add warning about known issues to documentation of cvsimport
From: Junio C Hamano @ 2009-03-31 23:55 UTC (permalink / raw)
To: Jeff King; +Cc: Heiko Voigt, Chris Johnsen, git
In-Reply-To: <20090331194056.GA23102@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Going back to the original discussion, it looks like it is a workaround
> for docbook-xsl 1.69.0:
>
> http://article.gmane.org/gmane.comp.version-control.git/32957
>
> Assuming that is correct, I think the sane choices are:
>
> 1. drop the workaround, as that version of docbook-xsl is now several
> years old
>
> or
>
> 2. turn the workaround off by default, but add a knob to turn it on
> (DOCBOOK_XSL_1690?)
>
> Having it on by default and turning it off with a knob seems silly,
> since most versions don't need it. Debian stable is shipping 1.73 these
> days, which looks fine without 7ef0435. Are there other platforms still
> shipping 1.69.0? Is it too old for us to care?
I am very tempted to say 1. but we seem to have a track record of trying
to be nice to people. How involved would 2 be compared to 1?
^ permalink raw reply
* Re: [PATCH] git-gui: make "Git GUI Here" Explorer extension more robust
From: Markus Heidelberg @ 2009-03-31 23:59 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: Shawn O. Pearce, msysgit, git
In-Reply-To: <499F039601E4A981@joe.mail.tiscali.sys>
Giuseppe Bilotta, 31.03.2009:
> On Monday 30 March 2009 16:15, Shawn O. Pearce wrote:
>
> > Markus Heidelberg <markus.heidelberg@web.de> wrote:
> >>
> >> But I just noticed, that it will obviously "cd .." forever, if no .git/
> >> was found. Somehow the root directory has to be catched.
> >
> > Yup. I'm dropping this patch for now because of this issue, but
> > I'll look at it again if its addressed in another version. :-)
>
> I have a couple of pending patches to fix git gui handling of repositories,
> including support for nonstandard repository locations and bare repositories.
> You can find them at
>
> http://git.oblomov.eu/git
>
> and specifically
>
> http://git.oblomov.eu/git/patches/b2e4c32e13df1b7f18e7b4a9f746650471a3122e..a63526bf3238cf25d9a5521f7ee35ed1bd11cb16
I just tried these two patches on Windows (Uhh, Qemu is too slow for
this, I have to setup something else).
> I got distracted by real-life issue and forgot to resend them. I'll try
> to find the time again later on this week. I'm not entirely sure these
> solve Markus' problem though.
Starting git-gui via Explorer "Git GUI Here" is now possible from the
.git/ directory with your patches, but it doesn't show the working tree
status. Also "Explore Working Copy" wants to open the .git directory
then instead of the project directory (I say "want" because of the issue
I just sent a patch out). It seems to be as non-functional as if you run
"git status" inside of .git/
Markus
^ permalink raw reply
* Re: [RFC GSoC 2009: git-submodule for multiple, active developers on active trees]
From: Johannes Schindelin @ 2009-04-01 0:58 UTC (permalink / raw)
To: P Baker; +Cc: Shawn O. Pearce, git
In-Reply-To: <526944450903311649q358d43edkf07e2e5058a9e527@mail.gmail.com>
Hi,
On Tue, 31 Mar 2009, P Baker wrote:
> I'll paraphrase to see if I understand your points:
>
> *Moving objects from submodule .git directories into the base .git/
> directory would protect the submodules and is a good idea.
No, I did not say that.
I said that moving submodules' working directory need to protected when
renaming/deleting submodules.
Even worse, I think that moving the .git/ directory into the
superproject's .git/ would be at least quite a bit awkward in the nested
case.
> *Moving to a .git/ file from .gitmodules should be taken off of the
> goal list (I went back and read this thread:
> http://thread.gmane.org/gmane.comp.version-control.git/78605; seemed
> to clear things up).
Can't follow links here, as I am reading this offline, so cannot comment.
> *git submodule recurse would be a good option (not as a default), if
> the remaining issues are resolved.
Definitely.
> *It would be a good idea for git submodule to work with foreign VCS,
> through Daniel's patches.
But that would not only apply to submodules, but rather all repositories,
to the point that "git submodule" does not need any change.
> I appreciate the guidance, it's helping me to see that some of this work
> has already been done, it needs to be finished and pushed into a public
> release. As an intense user of submodules, what does it do poorly/not do
> for your needs?
One gripe I have, but which should be rather easy to fix: "git checkout --
submodule/" does not update the index, last time I checked. (It correctly
does not touch the submodule's working directory.)
Another one: The most common mistake with submodules is to commit and push
the superproject, after having committed (but not pushed) in the
submodule. Not sure how that could be helped.
Further, often it would come in rather handy to be able to say something
like "git diff $REVISION_AS_COMMITTED_IN_THE_SUPERPROJECT" from within
the submodule...
git submodule summary should output to the pager by default.
Oh, and it would not hurt performance on Windows at all if git-submodule
would be finally made a builtin.
Ciao,
Dscho
^ permalink raw reply
* Re: On git 1.6 (novice's opinion)
From: Kris Shannon @ 2009-04-01 2:32 UTC (permalink / raw)
To: Ulrich Windl; +Cc: Git Mailing List
In-Reply-To: <49CC8C90.12268.242CEFCE@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de>
2009/3/27 Ulrich Windl <ulrich.windl@rz.uni-regensburg.de>:
> 2) Keyword substitution. I know it's controverse (dealing with binary files),
> but I'd like to have some automatic version numbering keyword at least:
> Initial idea is that every commit with a change increments the number by one,
> and when merging numbers a and b, the resulting number is max(a, b) + 1.
Check out gitattributes(5) - the ident attribute:
When the attribute ident is set for a path, git replaces $Id$ in the blob
object with $Id:, followed by the 40-character hexadecimal blob object name,
followed by a dollar sign $ upon checkout. Any byte sequence that begins
with $Id: and ends with $ in the worktree file is replaced with $Id$ upon
check-in.
That means the Id is file specific, not commit specific - just like the $Id$
expansion for CVS and SCCS is about the file (as there is no real concept
of a commit in CVS and SCCS)
^ permalink raw reply
* Re: [RFC GSoC 2009: git-submodule for multiple, active developers on active trees]
From: P Baker @ 2009-04-01 2:47 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Shawn O. Pearce, git
In-Reply-To: <alpine.DEB.1.00.0904010247170.10279@pacific.mpi-cbg.de>
> > *Moving objects from submodule .git directories into the base .git/
> > directory would protect the submodules and is a good idea.
>
>
> No, I did not say that.
>
> Even worse, I think that moving the .git/ directory into the
> superproject's .git/ would be at least quite a bit awkward in the nested
> case.
>
Tthe initial prompt for the proposal was: "Rewrite git-submodule,
placing the repository for each referenced submodules in the
superproject's $GIT_DIR/modules...This resolves issues related to
switching between versions of the superproject..." The prompt, and
past experience with git, helped me to form my proposal which it seems
would fix numerous problems with git submodule, with the implied cost
of some awkwardness/complexity. Am I misunderstanding the prompt? Or
do you think this could be accomplished more elegantly?
> I said that moving submodules' working directory need to protected when
> renaming/deleting submodules.
I'm sorry, I still don't understand. Where would this occur? What is
being protected? What is the submodules' working directory? I'm still
learning the intricacies of git, so I'd appreciate any pointers you
can give.
>
>
> > *It would be a good idea for git submodule to work with foreign VCS,
> > through Daniel's patches.
>
>
> But that would not only apply to submodules, but rather all repositories,
> to the point that "git submodule" does not need any change.
>
>
Fair enough. There's plenty of other work to be done!
> > I appreciate the guidance, it's helping me to see that some of this work
> > has already been done, it needs to be finished and pushed into a public
> > release. As an intense user of submodules, what does it do poorly/not do
> > for your needs?
>
>
> One gripe I have, but which should be rather easy to fix: "git checkout --
> submodule/" does not update the index, last time I checked. (It correctly
> does not touch the submodule's working directory.)
>
I'll add it to the list. In terms of general gripes: git submodule add
(or all of git submodule?) handles relative links poorly (see
http://kerneltrap.org/mailarchive/git/2007/12/10/485597). And the
'Gotchas' listed at
http://git.or.cz/gitwiki/GitSubmoduleTutorial#head-a3cba9cbd1e125c0667dfb3b9249100be7f815ad.
> Another one: The most common mistake with submodules is to commit and push
> the superproject, after having committed (but not pushed) in the
> submodule. Not sure how that could be helped.
>
Seems like this is on the git submodule wiki 'Gotcha' list, too.
There's a spectrum of options: failing, warning, generating an output
message, etc. I think it is worth working on. What is git's policy on
interrupting users when their actions _could_ be counterproductive to
their intentions? Would hooks on the submodule's commit written by the
user fix this? That's not a built-in solution.
> Further, often it would come in rather handy to be able to say something
> like "git diff $REVISION_AS_COMMITTED_IN_THE_SUPERPROJECT" from within
> the submodule...
>
That sounds complex, and would break expectations. This would only
work if git in the submodule working directory knows its a submodule.
Is there a way to reference it's super project?
> git submodule summary should output to the pager by default.
>
Added to the list.
> Oh, and it would not hurt performance on Windows at all if git-submodule
> would be finally made a builtin.
You mean rewriting git-submodule.sh in C? What other impacts might that have?
Thanks,
Phillip Baker
> Ciao,
> Dscho
>
>
^ permalink raw reply
* Re: Segfault on merge with 1.6.2.1
From: Michael Johnson @ 2009-04-01 5:43 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <op.urnad7jbso3nzr@sulidor.mdjohnson.us>
On Tue, 31 Mar 2009 02:14:21 -0500, Michael Johnson
<redbeard@mdjohnson.us> wrote:
> That said, here's my backtrace. I've tried tracing through to figure out
> where the problem is occurring, but my gdb-foo is non-existent, I'm
> wating for some GUIs to install, and I'm ready for some sleep :| So if I
> haven't heard back by tomorrow evening, I'll be running one of the
> frontends for gdb until I have something traced down :)
I tried tracing it manually with KDbg tonight. But either I'm too tired
(and my patience is low), or I'm just not capable of understanding it. I
hope it's the former, since I was able to follow the basic flow well
enough. But I still wasn't terribly happy with the front end. It's obvious
that gdb is awesome, I'm just not ready for it yet :)
Anyway, I decided to try an experiment, as I had mentioned to someone that
if I couldn't get this bug tracked down, I'd have to do the merge
manually. So... I figured out the common ancestor (I used git show-branch,
but I'm betting there's an easier way), and merged the ancestor + 1 of the
other branch into my HEAD. It segfaulted. So, I tried the resolve strategy
at the same point. Amazingly, it worked. And a default recursive merge
handled the rest.
That means my current problem is resolved, but I'm guessing a segfault on
a default merge is still a bad thing, so I'll try to keep up on this. I do
have a copy of the repository before the merge (several, right now,
actually), so I can try fixes. If I'm lucky I'll have some time to work on
it myself. But it will be at least two weeks before I actually have the
time to personally track down the problem without help. However, I should
be able to assist someone else fairly easily.
In short, I don't personally need a fix right now, but I can help figure
out what is broken with it.
Thanks,
Michael
--
Michael D Johnson <redbeard@mdjohnson.us>
redbeardcreator.deviantart.com
"Marketing research...[has] shown that energy weapons that make sounds sell
better..." - Kevin Siembieda (Rifts Game Master Guide, pg 111)
^ permalink raw reply
* Re: [PATCH 07/10] rev-list: call new "filter_skip" function
From: Christian Couder @ 2009-04-01 6:09 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git, John Tapsell
In-Reply-To: <alpine.DEB.1.00.0903311117400.10279@pacific.mpi-cbg.de>
Le mardi 31 mars 2009, Johannes Schindelin a écrit :
> Hi,
>
> On Tue, 31 Mar 2009, Christian Couder wrote:
> > Le lundi 30 mars 2009, Johannes Schindelin a écrit :
> > > On Mon, 30 Mar 2009, Christian Couder wrote:
> > > > Le jeudi 26 mars 2009, Junio C Hamano a écrit :
> > > > > I've learned to suspect without reading a qsort() callback that
> > > > > does not derefence its arguments. Is this doing the right thing?
> > > >
> > > > I think so.
> > >
> > > I suspect something much worse: you are trying to build a list of
> > > sha1s of commits that need to be skipped, later to look up every
> > > commit via binary search.
> > >
> > > But it has been proven a lot of times that using a hash set is
> > > superior to that approach, and even better: we already have the
> > > framework in place in the form of struct decorate.
> >
> > I had a look, and "struct decorate" can be used to store objects, but I
> > want to store only sha1s.
>
> No, you want to _look up_ sha1s. And struct decorate is not about
> storing objects, but to attach things to objects.
The problem is that I don't have any object to attach things to when I read
the bisect skip refs. I just need to store the sha1 from the skip refs in
some sha1 container.
Here is the related code:
static int register_ref(const char *refname, const unsigned char *sha1,
int flags, void *cb_data)
{
if (!strcmp(refname, "bad")) {
...
} else if (!prefixcmp(refname, "good-")) {
...
} else if (!prefixcmp(refname, "skip-")) {
ALLOC_GROW(skipped_sha1, skipped_sha1_nr + 1,
skipped_sha1_alloc);
hashcpy(skipped_sha1[skipped_sha1_nr++], sha1);
}
return 0;
}
static int read_bisect_refs(void)
{
return for_each_bisect_ref(register_ref, NULL);
}
Best regards,
Christian.
^ permalink raw reply
* Re: [RFC GSoC 2009: git-submodule for multiple, active developers on active trees]
From: Andreas Ericsson @ 2009-04-01 6:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: P Baker, Shawn O. Pearce, git
In-Reply-To: <alpine.DEB.1.00.0904010247170.10279@pacific.mpi-cbg.de>
Johannes Schindelin wrote:
> Hi,
>
> On Tue, 31 Mar 2009, P Baker wrote:
>
>> I'll paraphrase to see if I understand your points:
>>
>> *Moving objects from submodule .git directories into the base .git/
>> directory would protect the submodules and is a good idea.
>
> No, I did not say that.
>
> I said that moving submodules' working directory need to protected when
> renaming/deleting submodules.
>
> Even worse, I think that moving the .git/ directory into the
> superproject's .git/ would be at least quite a bit awkward in the nested
> case.
>
Not necessarily. The .git directory of a submodule need not be named .git
inside the superprojects .git directory. I could well imagine something
like this:
.git/modules/submod(.git)/modules/nested-submod(.git)
For deeply nested submodules (eurgh), one might run into path length limit
issues though. The point is that we will need some library-like function
to find the repository of the submodule. Once that's done, the same call
with a different $gitdir should be able to find the nested submodule.
I'm also thinking of libgit2 here, where each repository will be
represented as a struct that must be passed to the various $gitdir
searching functions. This is necessary to allow a single program to access
multiple repositories, and the .git/modules scheme makes supporting
submodules in the library quite trivial.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
^ permalink raw reply
* Re: On git 1.6 (novice's opinion)
From: Ulrich Windl @ 2009-04-01 6:45 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Dmitry Potapov, git
In-Reply-To: <vpq63hvdqs2.fsf@bauges.imag.fr>
On 27 Mar 2009 at 14:44, Matthieu Moy wrote:
> "Ulrich Windl" <ulrich.windl@rz.uni-regensburg.de> writes:
>
> > I don't understand:
> > If I modify files, then do a make, then do check-in/check-out (and the file times
> > are unchanged), how would that affect make?
>
> From "make"'s point of view, chechout is just a modification of the
> file (as any other modification you would do with a text editor). If
> you compile foo.c to foo.o, then checkout another version of foo.c,
> then you want foo.c to be recompiled. If checkout modifies the
> timestamp to pretend it was modified before foo.o, then make thinks
> the file is up to date.
>
> > If I do an "update/merge from remote" (there is no total ordering of release
> > numbers anyway) without a "make clean" before, I'm having a problem
> > anyway.
>
> No, you don't have a problem. Recompiling files after they're modified
> is the job of make, and it just does it. make doesn't know about
> revision numbers or identifiers, just timestamps.
Hi!
If you compiled a Linux kernel, then do an "upgrade" to the tree, it's quite
likely that a "make clean" after that upgrade does something different to the
"make clean" before the upgrade. Thus I'd "make clean" before the upgrade. (which,
I think, proves my point)
Regards,
Ulrich
^ permalink raw reply
* Re: On git 1.6 (novice's opinion)
From: Ulrich Windl @ 2009-04-01 6:50 UTC (permalink / raw)
To: Etienne Vallette d'Osia; +Cc: Dmitry Potapov, H.Merijn Brand, git
In-Reply-To: <49CCD90F.6090707@gmail.com>
On 27 Mar 2009 at 14:47, Etienne Vallette d'Osia wrote:
> Ulrich Windl a écrit :
> > AFAIK, "committing" in git is "kind of publishing your work" (others may pull it).
> > I don't like publishing my mistakes ;-) Even if no-one pulls the commit, your
> > "undo" refers to "committing a fix for the last committed mistake", right? Again,
> > I don't really want to document/archive (i.e. commit) my mistake. Or did I miss
> > something here?
> > I know: Other's opinions are quite different on these issues.
>
> commit is local.
I had made the experience that you can "pull" from a local directory (unless
permissions forbid it). As I can't control what others are doing, a "commit" is
still more or less making the results public (unless you can convince me that
I'm wrong). OK, I grew up with servers that host hundreds of users, not with
having my own laptop...
> The good way is to commit in your local and private repository.
> Then you can do anything, reset commit you have just done, etc
> When all is ok, you push in a public repository.
>
> With this workflow, no one see your local work and you can commit very
> often, undo commit, rebase a lot etc.
>
> The only result of a such job is a large number of useless objects in
> your local repository. They will be delete automatically by git, so it's
> not a problem.
>
> Regard,
> Etienne
^ permalink raw reply
* Re: On git 1.6 (novice's opinion)
From: Ulrich Windl @ 2009-04-01 6:59 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Michael J Gruber, git
In-Reply-To: <m3fxgz2h2n.fsf@localhost.localdomain>
On 27 Mar 2009 at 7:09, Jakub Narebski wrote:
> "Ulrich Windl" <ulrich.windl@rz.uni-regensburg.de> writes:
> > On 27 Mar 2009 at 13:49, Michael J Gruber wrote:
> > > Ulrich Windl venit, vidit, dixit 27.03.2009 08:21:
> >
> > [...]
> >
> > > Keyword substitution and cvs/svn style version numbers are independent
> > > issues. The sha1 describes a commit uniquely, one could use that as a
> > > keyword.
> >
> > However version numbers and time stamps have the property of being at least
> > partially ordered in respect of "newer/older". That property does not hold for
> > SHA-1 checksums. Just imagine suggesting users to upgrade from Microsoft
> > Word/004765c2a1e9771e886f0dbe87d4f89643cd6f70 to Microsoft
> > Word/00b7e6f51130f234a969c84ee9231a5ff7fc8a82 ;-)
>
> That is why people use output of git-describe and _tag_ their releases,
> and make embedding version number in released version (tarball / binary)
> the job of make: see GIT-VERSION-GEN script in git sources, and how it
> is used in Makefile.
OK, but imaginge someone sends you some file that originated from some git
version, maybe with minor modifications. Is there a way to find out from what git
version that file was derived? IMHO that's where "automatically replaced
placeholders" (like $id$) make sense.
>
> >
> > >
> > > Increasing version numbers are meaningless in a true DVCS world. What is
> > > your 100th commit may not be someone else's, even if both your master's
> > > heads are the same! This is why hg version numbers are a local thing.
> > > They are merely a local shortcut for specifying a revision and serve the
> > > same purpose as git's "backward" counts like HEAD~3 etc. Neither of them
> > > work permanently, not even in a local repo, if you allow rebasing.
> >
> > Maybe I didn't fully understand, but having a version number that is larger than
> > any parent's version numbers when doing a merge/commit doesn't look wrong to me.
>
> I'm sorry to dissapoint you, but without central server assigning
> numbers to commits it wouldn't simply work in distributed version
> control world. Take for example the following situation: somebody
> clones your repository, and creates new commit on 'master' (trunk) and
> it gets version number N. Meanwhile you also independently create new
> commit on 'master'... and without central authority it would also get
> version number N. Then you would merge (pull) his/her changes, and
> you would have two commits with the same number; not something you want.
Anyway the result would have number "N+1". Maybe you misunderstood: I'm not
proposing to replace git's internal version numbering (SHA-1), but so introduce
some more comprehensible, primitive user-level numbering.
>
> Not to mention that you can have multiple roots (multiple commits with
> no parent) in git repository; besides independent branches (like
> 'man', 'html' or 'todo') it is usually result of absorbing or
> subtree-merging other projects. In 'master' branch there are 5 roots
> or more: joined 'git-tools' (mailinfo / mailsplit), absorbed gitweb,
> and subtree-merged gitk and git-gui. And here you would again have
> multiple commits with the same number...
Which would not harm, because it would be version N from committer X. Any if
committer X merges from anything else, the next number would be > N. I did not
claim that my method makes a total ordering of commits and merges possible.
I truly believe in unique IDs, but they are just not handy in every situation.
[...]
Regards,
Ulrich
^ permalink raw reply
* Re: On git 1.6 (novice's opinion)
From: Andreas Ericsson @ 2009-04-01 7:29 UTC (permalink / raw)
To: Ulrich Windl; +Cc: Jakub Narebski, Michael J Gruber, git
In-Reply-To: <49D32CE5.21780.391D18@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de>
Ulrich Windl wrote:
> On 27 Mar 2009 at 7:09, Jakub Narebski wrote:
>
>> "Ulrich Windl" <ulrich.windl@rz.uni-regensburg.de> writes:
>>> On 27 Mar 2009 at 13:49, Michael J Gruber wrote:
>>>> Ulrich Windl venit, vidit, dixit 27.03.2009 08:21:
>>> [...]
>>>
>>>> Keyword substitution and cvs/svn style version numbers are independent
>>>> issues. The sha1 describes a commit uniquely, one could use that as a
>>>> keyword.
>>> However version numbers and time stamps have the property of being at least
>>> partially ordered in respect of "newer/older". That property does not hold for
>>> SHA-1 checksums. Just imagine suggesting users to upgrade from Microsoft
>>> Word/004765c2a1e9771e886f0dbe87d4f89643cd6f70 to Microsoft
>>> Word/00b7e6f51130f234a969c84ee9231a5ff7fc8a82 ;-)
>> That is why people use output of git-describe and _tag_ their releases,
>> and make embedding version number in released version (tarball / binary)
>> the job of make: see GIT-VERSION-GEN script in git sources, and how it
>> is used in Makefile.
>
> OK, but imaginge someone sends you some file that originated from some git
> version, maybe with minor modifications. Is there a way to find out from what git
> version that file was derived? IMHO that's where "automatically replaced
> placeholders" (like $id$) make sense.
>
Actually, that's where communication makes sense. With the CVS style keywords,
that file could have come from 1.3.7, or 2.9.1 (if it hasn't changed), and
the bug the changes are fixing might be in some other file entirely (such as
a header file on some particular system, but the offending call could well
be made in some other file).
If they build from the version control system, they're most likely quite
competent enough in finding the version number of the project they're using.
If they're building from sources, you can easily put the version number of
the project in every source-file you have with just a simple sed script.
Git makes that quite easy for you. Consider something like this:
--8<--8<-- release.sh --8<--8<--
#!/bin/sh
project=foo
latest_tag=$(git describe --abbrev=0)
version=$(echo tag | sed 's/^v//')
git archive --format=tar $latest_tag --prefix=$project-$version/ | \
sed s/@@VERSION@@/$version/ | \
gzip -9 > $project-$version.tar.gz
--8<--8<--8<--8<--
Now, if you put @@VERSION@@ as the keyword in all the source-files, all
the files released as anything but a clone of your version control system
will have a version tag that marks the version of your *project* rather
than some arbitrary number indicating how many times that particular file
has been changed over the course of your project.
I know which I prefer.
>>>> Increasing version numbers are meaningless in a true DVCS world. What is
>>>> your 100th commit may not be someone else's, even if both your master's
>>>> heads are the same! This is why hg version numbers are a local thing.
>>>> They are merely a local shortcut for specifying a revision and serve the
>>>> same purpose as git's "backward" counts like HEAD~3 etc. Neither of them
>>>> work permanently, not even in a local repo, if you allow rebasing.
>>> Maybe I didn't fully understand, but having a version number that is larger than
>>> any parent's version numbers when doing a merge/commit doesn't look wrong to me.
>> I'm sorry to dissapoint you, but without central server assigning
>> numbers to commits it wouldn't simply work in distributed version
>> control world. Take for example the following situation: somebody
>> clones your repository, and creates new commit on 'master' (trunk) and
>> it gets version number N. Meanwhile you also independently create new
>> commit on 'master'... and without central authority it would also get
>> version number N. Then you would merge (pull) his/her changes, and
>> you would have two commits with the same number; not something you want.
>
> Anyway the result would have number "N+1". Maybe you misunderstood: I'm not
> proposing to replace git's internal version numbering (SHA-1), but so introduce
> some more comprehensible, primitive user-level numbering.
>
It's been discussed to death and noone has been able to solve all the corner
cases. If you do, feel free to send the patches. In my experience though, the
git notation (HEAD~3) is totally superior to any made-up version numbers.
This is because in 99% of the cases where you're referring to anything but
"latest", you're either interested in some stable release (which should be
tagged, so you get to pick whatever version number you want) for diffing
purposes, or you want a *range* of commits (to send as patches, or to give
as an indication of "I think something happened somewhere here"), and the
backward count notation of git fits that mindset a whole lot better than
having numbers that increment from the start, and therefore quickly become
as unwieldy as the SHA1's for the human brain.
>> Not to mention that you can have multiple roots (multiple commits with
>> no parent) in git repository; besides independent branches (like
>> 'man', 'html' or 'todo') it is usually result of absorbing or
>> subtree-merging other projects. In 'master' branch there are 5 roots
>> or more: joined 'git-tools' (mailinfo / mailsplit), absorbed gitweb,
>> and subtree-merged gitk and git-gui. And here you would again have
>> multiple commits with the same number...
>
> Which would not harm, because it would be version N from committer X. Any if
> committer X merges from anything else, the next number would be > N. I did not
> claim that my method makes a total ordering of commits and merges possible.
>
> I truly believe in unique IDs, but they are just not handy in every situation.
>
What do they solve that the HEAD~3 syntax does not?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
^ permalink raw reply
* Re: On git 1.6 (novice's opinion)
From: Ulrich Windl @ 2009-04-01 7:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7veiwi5t8j.fsf@gitster.siamese.dyndns.org>
On 27 Mar 2009 at 18:30, Junio C Hamano wrote:
> "Ulrich Windl" <ulrich.windl@rz.uni-regensburg.de> writes:
>
> > ... Also some seemingly dangerous commands that cannot easily be undone
> > should ask safety questions ("cvs merge (-j)" would also fall into that
> > category.
>
> This is slightly an interesting point.
>
> In CVS and Subversion, "merge" (rather "update") can be a dangerous
> operation. You start working, you keep building, and you eventually
> accumulate quite a lot of changes but you still cannot see the end of the
> tunnel. Your changes are incomplete and you will upset others if you
> commit. Your changes are extensive enough that it can conflict heavily
> with what others have done already, and there is a high chance that you
> can screw up the merging but there is no easy way (unless you tar-up the
> whole work tree before attempting to update) to get back to the state
> before your merge. Damned if you commit, damned if you don't. You lose
> either way.
>
> This is because you cannot have a local commit. The problem is inherent
> to the centralized nature of these systems.
>
> Distributed systems are different. Unlike CVS/Subversion's
>
> work work work; then
>
> update to merge, risk screwing up the work in progress (or almost
> finished work); then
>
> commit
>
> workflow, in a distributed system, you first commit and then merge,
> preferably from a clean slate. You will not have to worry about screwing
> up the conflict resolution, because both states (what the other guy did,
> and what you did) are committed safely away and you can reset back to the
> state before you start your merge.
Hi!
OK, that example is not that dangerous in git, but git also has commands a
beginner could make some undesired damage ("git rebase", maybe).
Regards,
Ulrich
^ permalink raw reply
* Re: On git 1.6 (novice's opinion)
From: Ulrich Windl @ 2009-04-01 7:40 UTC (permalink / raw)
To: Bryan Donlan; +Cc: git
In-Reply-To: <3e8340490903282241u355ce5b3u1a6ff23b27f4ec12@mail.gmail.com>
On 29 Mar 2009 at 1:41, Bryan Donlan wrote:
> On Fri, Mar 27, 2009 at 3:21 AM, Ulrich Windl
> <ulrich.windl@rz.uni-regensburg.de> wrote:
>
>
> > 3) "git undo": If possible undo the effects of the last command.
>
> You can roll back the state of most local references by using the git
> reflog (see git reflog --help for more information). This covers most
> situations - but note that it only works to roll back to a committed
> state, and won't save any uncommitted data at all.
Hmm...kind of an idea:
"git undo <command>" print help text on how to undo the effect of <command>.
I feel that may be useful. maybe replace "undo" with "undo-instructions".
Regards,
Ulrich
^ permalink raw reply
* Re: On git 1.6 (novice's opinion)
From: Ulrich Windl @ 2009-04-01 7:42 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0903291149460.10279@pacific.mpi-cbg.de>
On 29 Mar 2009 at 11:50, Johannes Schindelin wrote:
> Hi,
>
> On Sun, 29 Mar 2009, Bryan Donlan wrote:
>
> > On Fri, Mar 27, 2009 at 3:21 AM, Ulrich Windl
> > <ulrich.windl@rz.uni-regensburg.de> wrote:
> >
> > > 3) "git undo": If possible undo the effects of the last command.
> >
> > You can roll back the state of most local references by using the git
> > reflog (see git reflog --help for more information). This covers most
> > situations - but note that it only works to roll back to a committed
> > state, and won't save any uncommitted data at all.
>
> Which is why you should commit early and often, and certainly before doing
> something bigger.
A user will only "commit" if he knows how to "undo" it. Proposing to use "commit"
to help with "undo" is a partial solution at best...
>
> Ciao,
> Dscho
>
^ permalink raw reply
* Re: On git 1.6 (novice's opinion)
From: Matthieu Moy @ 2009-04-01 7:41 UTC (permalink / raw)
To: Ulrich Windl
Cc: Etienne Vallette d'Osia, Dmitry Potapov, H.Merijn Brand, git
In-Reply-To: <49D32ABF.11569.30BC41@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de>
"Ulrich Windl" <ulrich.windl@rz.uni-regensburg.de> writes:
> On 27 Mar 2009 at 14:47, Etienne Vallette d'Osia wrote:
>
>> Ulrich Windl a écrit :
>> > AFAIK, "committing" in git is "kind of publishing your work" (others may pull it).
>> > I don't like publishing my mistakes ;-) Even if no-one pulls the commit, your
>> > "undo" refers to "committing a fix for the last committed mistake", right? Again,
>> > I don't really want to document/archive (i.e. commit) my mistake. Or did I miss
>> > something here?
>> > I know: Other's opinions are quite different on these issues.
>>
>> commit is local.
>
> I had made the experience that you can "pull" from a local directory (unless
> permissions forbid it). As I can't control what others are doing, a "commit" is
> still more or less making the results public (unless you can convince me that
> I'm wrong). OK, I grew up with servers that host hundreds of users, not with
> having my own laptop...
Multi-users server, or NFS-shared $HOME, yes, expose every working
tree and therefore directories to other users. But still, the good
practice would be to distinguish your working area, and a "clean"
area if you want to get all the power of distributed version control.
One of the main points in having version control distributed is
precisely to allow you to distinguish private things and published
ones (i.e. commit != push). Linus explains this better than I do in
his talk:
http://www.youtube.com/watch?v=4XpnKHJAok8
You _can_ expose your working tree directly to others, but if you do
so, you'll have to forget about "git commit --amend",
"git reset <anything-else-than-HEAD>", "git rebase",
"git filter-branch", ... (any history-editing feature of Git indeed).
OTOH, the common setup for people is to have a workstation (laptop or
desktop) without a public access (for example, my home computer is
switched of when I'm not using it, and my office station is only
reachable from outside with ssh), and to publish things on another
server. So, in the common case, the distinction private/public is
natural.
--
Matthieu
^ permalink raw reply
* Re: On git 1.6 (novice's opinion)
From: Matthieu Moy @ 2009-04-01 7:42 UTC (permalink / raw)
To: Ulrich Windl; +Cc: Dmitry Potapov, git
In-Reply-To: <49D329A0.10769.2C57DE@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de>
"Ulrich Windl" <ulrich.windl@rz.uni-regensburg.de> writes:
> If you compiled a Linux kernel, then do an "upgrade" to the tree, it's quite
> likely that a "make clean" after that upgrade does something different to the
> "make clean" before the upgrade. Thus I'd "make clean" before the upgrade. (which,
> I think, proves my point)
But why do a "make clean", at all?
--
Matthieu
^ permalink raw reply
* Re: On git 1.6 (novice's opinion)
From: Ulrich Windl @ 2009-04-01 7:53 UTC (permalink / raw)
To: Russ Dill; +Cc: H.Merijn Brand, git
In-Reply-To: <f9d2a5e10903292318w6108bc50u2ddc830a6d9d85df@mail.gmail.com>
On 29 Mar 2009 at 23:18, Russ Dill wrote:
> On Fri, Mar 27, 2009 at 2:50 AM, Ulrich Windl
> <ulrich.windl@rz.uni-regensburg.de> wrote:
> > On 27 Mar 2009 at 9:05, H.Merijn Brand wrote:
> >
> >> On Fri, 27 Mar 2009 08:21:36 +0100, "Ulrich Windl"
> >> <ulrich.windl@rz.uni-regensburg.de> wrote:
> >>
> >> > What I'd like to see in git (My apologies if some were already discussed to
> >> > death):
> >> >
> >> > 1) The ability to use the file's time at the time of add/commit instead of
> >> > the current time, and the ability tho check outfiles with the times stored
> >> > in the repository.
> >> >
> >> > 2) Keyword substitution. I know it's controverse (dealing with binary files),
> >> > but I'd like to have some automatic version numbering keyword at least:
> >> > Initial idea is that every commit with a change increments the number by
> >> > one, and when merging numbers a and b, the resulting number is max(a, b) + 1.
> >>
> >> impossible. Even with checkin- and checkout hooks, you won't get that
> >> SCCS behaviour. They have to be better in something too :)
> >> /me still misses that but got used to it
> >
> > Hi,
> >
> > what made me wonder is this (about item 1): I thought I've read that blobs store
> > content and attributes, so very obviously I wondered why not store thr "right
> > attributes" (i.e. the time of the file). My reasoning: You make some changes, then
> > test them (which might last several hours or days). The if I'm happy I'll
> > "commit". Naturally I want to see the time of change for each file when the change
> > had been actually made, not when the change was committed. Likewise when checking
> > out, I want to be able to see the time of modification, not the time of commit.
> > I'm aware that many people don't care about such differences...
> >
>
> Ok, so if Nancy did some work on the part number form 6 months ago,
> but it got merged into master yesterday. What date should the file
> have? This kind of incremental version number, and trusting of file
If Nancy committed it with my semantics, the file's date would be 6 months old
before the merge. If the merge would not require any change, the file's date would
still be six months old. If a change was required, the file's date would be the
time of change. That sounds quite logical to me.
> dates really only matters on a centralized system with a single
> branch.
>
> Not only that, but modification times are much more useful with make.
> Merging or pulling small changes into a tree shouldn't require a full
> rebuild of the entire tree which in some cases could take hours.
Git is not a build system, and I really dislike "full rebuilds", but for
stability, before releasing anything, one should test it with a full rebuild. I
think that's what configuration management systems are about. So for a merge or
checkout of any make source object (opposed to: make target object), an automated
cleanup of the corresponding target objects should be made. I know that you don't
like it, but for RCS you have the couce whether to check-in with "-d", or check
out with "-M". If it's optional in GIT also, you shouldn't be unhappy.
> Especially since 'git log <file>', 'gitk <file>', or 'git blame
> <file>' give much more information anyway.
>
> I know some people sort their directory by date to see what kind of
> stuff happened since they last worked on the repository, but it
> doesn't scale to a project with many directories and the log is much
> more useful anyway.
I agree.
Regards,
Ulrich
^ permalink raw reply
* [PATCH] builtin-clone.c: make junk_pid static
From: Ali Gholami Rudi @ 2009-04-01 8:04 UTC (permalink / raw)
To: git
junk_pid is used only in builtin-clone.c.
Signed-off-by: Ali Gholami Rudi <ali@rudi.ir>
---
builtin-clone.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-clone.c b/builtin-clone.c
index 0031b5f..736c72c 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -270,7 +270,7 @@ static const struct ref *clone_local(const char *src_repo,
static const char *junk_work_tree;
static const char *junk_git_dir;
-pid_t junk_pid;
+static pid_t junk_pid;
static void remove_junk(void)
{
^ permalink raw reply related
* Re: On git 1.6 (novice's opinion)
From: Matthieu Moy @ 2009-04-01 7:54 UTC (permalink / raw)
To: Ulrich Windl; +Cc: Jakub Narebski, Michael J Gruber, git
In-Reply-To: <49D32CE5.21780.391D18@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de>
"Ulrich Windl" <ulrich.windl@rz.uni-regensburg.de> writes:
>> Not to mention that you can have multiple roots (multiple commits with
>> no parent) in git repository; besides independent branches (like
>> 'man', 'html' or 'todo') it is usually result of absorbing or
>> subtree-merging other projects. In 'master' branch there are 5 roots
>> or more: joined 'git-tools' (mailinfo / mailsplit), absorbed gitweb,
>> and subtree-merged gitk and git-gui. And here you would again have
>> multiple commits with the same number...
>
> Which would not harm, because it would be version N from committer X. Any if
> committer X merges from anything else, the next number would be > N. I did not
> claim that my method makes a total ordering of commits and merges possible.
Neither does it make the numbers unique for committer X.
If commiter X commits a successor to commit N, it's labeled N+1. If
later, he creates another branch from commit N, and commit, the new,
other commit will be labeled N+1.
This means even within a repository, you cannot say things like
"commit number N", so, OK, you have numerical IDs, but you can't use
them.
What can be interesting is that a commit takes
max{all commits in repository}+1, not just max{parents} + 1. Then, you
have local revision numbers, but they're not stable. Indeed, that's
precisely what Mercurial does.
But I'm not sure how much simplicity it adds compared to the confusion
it adds. Newbies will see Mercurial identifiers as
changeset: 2:699b81a5851b
changeset: 1:fd4b6597548f
changeset: 0:58cff172192e
And think "OK, the revision numbers are 0, 1, 2, and the hexadecimal
stuff beside is useless". And one day, he'll send a mail, post a
bugreport, or whatever, saying "I have a problem with revision number
42", and no one else but him will know which revision is called "42".
> I truly believe in unique IDs, but they are just not handy in every situation.
Usually, people find Git IDs to be non-handy until the find out they
can cut-and-paste only the first few digits in most cases, like
442dd42 instead of 442dd42d6d4903640b0dc5561481a77c88dcea90 ;-).
--
Matthieu
^ permalink raw reply
* Re: On git 1.6 (novice's opinion)
From: Ulrich Windl @ 2009-04-01 8:15 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <49D08B8B.1000309@op5.se>
On 30 Mar 2009 at 11:06, Andreas Ericsson wrote:
[...]
> 3 It's far better to set the version number in the release-process. Usually
> this can be done automatically by one invocation of "git describe", just
> as git.git does it.
However if you put a version number into every file and THEN commit, it's somewhat
ridiculous (I'll have to learn about "git describe"). But for configuration
management you want to have exactly that (find exactly the file that was shipped
(or used to build)).
>
> We've adopted "3" full out at $dayjob. Our build-machinery gets the version
> number from the git tag (releases can only be built from signed tags), and
> it updates macros and whatnot used for informing the user which version he
> or she is running. This makes a lot more sense both from a bug-reporting
> and from a release process view than having generated version-numbers in
So your "release commits" are outside GIT? (see above)
> files. On a side-note; When I told my co-workers I'd like us to switch to
> git, two of them asked about autoversioning features. I said there weren't
> any and asked them to name a single time when we've actually used them for
> anything *at all*. In a team of eight, having been programming for three
> years with 12 releases and about 800 bugreports + feature-requests, noone
> could mention a single time when the autogenerated version numbers had
> actually been used for anything.
Hmm: Were they visible to customers?
>
> Otoh, having the entire repository locally makes it painless to view the
> commit-log for an entire project (or parts of it) and see who changed what
> when and why, which is information that's actually *useful*.
[Big meals need time to digest: Just give me more time to do so (getting into
git). As with vi and Emacs (usualy I prefer Emacs), there will be situations when
I won't use Git however]
Regards,
Ulrich
^ permalink raw reply
* Re: [PATCH 0/4] send-email: correct various issues
From: Matthieu Moy @ 2009-04-01 8:33 UTC (permalink / raw)
To: Jay Soffian
Cc: git, Junio C Hamano, Björn Steinbrink, Uwe Kleine-König
In-Reply-To: <cover.1238516122.git.jaysoffian@gmail.com>
Jay Soffian <jaysoffian@gmail.com> writes:
> Junio, these are technically all independent bug fixes, but they were
> minor, so I've lumped them together. I figured you'd just add them to
> the js/send-email topic anyway. Also, I apologize for causing trouble in
> master. :-(
But I shall thank you for fixing them ;-).
> Jay Soffian (4):
> send-email: don't attempt to prompt if tty is closed
Works, I don't have garbage anymore in my logs.
> send-email: ask_default should apply to all emails, not just the
> first
Works, I get the informational message in my logs once, and all the
mails are sent successfully.
> send-email: correct two tests which were going interactive
> send-email: ensure quoted addresses are rfc2047 encoded
Didn't test these.
--
Matthieu
^ 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