* Re: Suggested Workflow Question
From: Marcel M. Cary @ 2009-03-18 1:27 UTC (permalink / raw)
To: Roger Garvin; +Cc: git@vger.kernel.org
In-Reply-To: <loom.20090317T175010-470@post.gmane.org>
Roger Garvin wrote:
> I work for a small company with about 15 developers who work concurrently on
> about 10+ projects both in new development and support.
> We do custom software for manufacturing and production systems. Part of our
> contracts with our customers is a perpetual single use license of the source
> code at each facility.
> So we have a copy of the source on our office server, and another copy at each
> customer site. When we had only 5 developers it was easier to handle. Now that
> we are growing we need a source control system and I have been looking heavily
> into Git. Our old workflow does not seem that it will fit well with Git
> however, but I feel that I need a distributed system to keep track of the office
> version and the on-site versions of our source since development is taking place
> on both.
> (Some customers also have separate development, and testing versions on their
> servers as well.)
>
> I have created git repositories on a couple of our project source directories as
> test beds. Right now (second day) I am the only one who is actually using git.
> Everyone else is simply accessing the files on the server as they have always
> done, and I am making the commits when I see signifigant changes.
>
> My question is really a request for modified workflow ideas. My plan was to
> have a master repository in our office server with clones at each customer site,
> and multiple branches for test, QA, and production versions of the source.
> Since most of these customers have closed networks, we would rely on people
> traveling onsite, or emailing patches to get any updates back into our office
> repository.
>
> Thank you for any assistance for this revision control newb.
>
> Roger Garvin
The workflow elements you mention so far sound sane to me:
* a repository in your office
* repositories at customer sites
* emailing patches when direct connections are not possible
* test and dev branches for each customer
I presume there will also be a production branch in customer
repositories on which you arrange production releases... or maybe you
just tag your test branch when it passes?
When you send patches via email, keep in mind that you'll have to convey
which branch they belong on "out of band", for example after the commit
message and above the diffstat.
There was an interesting discussion about maintaining per-client code on
different branches recently, but I can't find it.
I've found Git to be very flexible. Maybe you could start by emulating
your current workflow and refine it as you go? If you find you don't
know how code travels currently... well, maybe you can just let your
team pass patches around until patterns emerge.
Marcel
^ permalink raw reply
* Re: [PATCH] git config: clarify bool types
From: Junio C Hamano @ 2009-03-18 1:13 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, Johannes Schindelin
In-Reply-To: <1237331631-29822-1-git-send-email-felipe.contreras@gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> The value is what it is, the --bool and --bool-or-int options don't
> specify the value type, just how it is interpreted. For example: a value
> of '1' can be interpreted as 'true'.
>
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> ---
>
> This applies on top of the 'next' branch.
>
> builtin-config.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/builtin-config.c b/builtin-config.c
> index 1a3baa1..c3a0176 100644
> --- a/builtin-config.c
> +++ b/builtin-config.c
> @@ -66,9 +66,9 @@ static struct option builtin_config_options[] = {
> OPT_STRING(0, "get-color", &get_color_slot, "slot", "find the color configured: [default]"),
> OPT_STRING(0, "get-colorbool", &get_colorbool_slot, "slot", "find the color setting: [stdout-is-tty]"),
> OPT_GROUP("Type"),
> - OPT_BIT(0, "bool", &types, "value is \"true\" or \"false\"", TYPE_BOOL),
> + OPT_BIT(0, "bool", &types, "value is intepreted as bool (\"true\" or \"false\")", TYPE_BOOL),
I'd rater see it say something like:
Output the value as boolean (true or false)
so that it is consistent with others you can see in the context.
E.g. get-color explains it to order the command to "find the color".
"Interpret" is fine too. The point is not about the choice of verb but
use of imperative mood.
^ permalink raw reply
* Re: Ability to edit message from git rebase --interactive.
From: Junio C Hamano @ 2009-03-18 1:06 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, Olivier Goffart, git
In-Reply-To: <20090318004056.GB25454@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Tue, Mar 17, 2009 at 11:31:19PM +0100, Johannes Schindelin wrote:
>
>> > I was told on IRC that this has been discussed already not so long ago,
>> > and looking on the archive[1], all i seen was bikesheeding . Here is a
>> > patch :-)
>>
>> Unfortunately, the implementation is not the problem, but picking the best
>> name. The first letter "m" will be taken in a short while by the "merge"
>> command for "rebase -i -p", so "message" is out, sadly.
>>
>> But the "rephrase" command will be part of the "rebase -i -p" series when
>> I will finally be able to submit it.
>
> Also, I thought the general plan was to add such features to the
> git-sequencer work which will (hopefully) eventually replace "rebase
> -i". Dscho, can you give a brief update on how that is coming? Are
> rebase patches worth thinking about?
I am not quite sure what rephrase is buying us. Do we also want to
introduce retree that allows you to muck with the tree object recorded
without giving you a chance to clobber the commit log message?
^ permalink raw reply
* Re: push.default, was Re: What's cooking in git.git (Mar 2009, #04; Sat, 14)
From: Junio C Hamano @ 2009-03-18 1:05 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Nanako Shiraishi, git
In-Reply-To: <alpine.DEB.1.00.0903180138210.10279@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> In my git.git clone on one machine, I have remote.orcz.push = master. I
> cloned it. There, "git push" does something different.
>
> Inconsistent right there, correct? Without any change to git.git.
You must be smoking something potent. It's a nonsense argument and you
know it.
In your git.git clone on one machine, you have some setting.
You cloned it to one machine some time ago. It behave differently and
that is something that has always been true, and you know it. Repository
configuration is private.
You clone it to another today. Now the new clone, without any
configuration, will behave differently from the other clone, that you
haven't done any funny configuration.
That's inconsistent.
^ permalink raw reply
* Re: [PATCH] builtin-tag.c: remove global variable to use the callback data of git-config.
From: Carlos Rica @ 2009-03-18 0:50 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: gitster, git
In-Reply-To: <alpine.DEB.1.00.0903172326250.10279@pacific.mpi-cbg.de>
On Tue, Mar 17, 2009 at 11:27 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Tue, 17 Mar 2009, Carlos Rica wrote:
>
>> On Tue, Mar 17, 2009 at 4:47 PM, Johannes Schindelin
>> <Johannes.Schindelin@gmx.de> wrote:
>> > Hi,
>> > On Tue, 17 Mar 2009, Carlos Rica wrote:
>> >> @@ -164,11 +162,10 @@ static int do_sign(struct strbuf *buffer)
>> >> int len;
>> >> int i, j;
>> >>
>> >> - if (!*signingkey) {
>> >> - if (strlcpy(signingkey, git_committer_info(IDENT_ERROR_ON_NO_NAME),
>> >> - sizeof(signingkey)) > sizeof(signingkey) - 1)
>> >> - return error("committer info too long.");
>> >> - bracket = strchr(signingkey, '>');
>> >> + if (!signingkey->buf[0]) {
>> >
>> > It is probably better to ask for !signingkey->len (think of trying to
>> > understand the code in 6 months from now).
>>
>> I was in doubt here. By avoiding the use of signingkey->len I was
>> trying to say that you cannot rely in such field if we touch the
>> buffer directly, as it happens below:
>>
>> bracket = strchr(signingkey->buf, '>');
>> if (bracket)
>> bracket[1] = '\0';
>
> Oh, I missed that. It should read
>
> if (bracket)
> strbuf_setlen(signingkey, bracket + 1 - signingkey->buf);
>
> instead.
I agree! That's much better. Thanks Dscho and Junio.
Tell me if you need me to resend the patch with both changes.
^ permalink raw reply
* Re: Ability to edit message from git rebase --interactive.
From: Johannes Schindelin @ 2009-03-18 0:58 UTC (permalink / raw)
To: Jeff King; +Cc: Olivier Goffart, git
In-Reply-To: <20090318004056.GB25454@coredump.intra.peff.net>
Hi,
On Tue, 17 Mar 2009, Jeff King wrote:
> On Tue, Mar 17, 2009 at 11:31:19PM +0100, Johannes Schindelin wrote:
>
> > > I was told on IRC that this has been discussed already not so long ago,
> > > and looking on the archive[1], all i seen was bikesheeding . Here is a
> > > patch :-)
> >
> > Unfortunately, the implementation is not the problem, but picking the best
> > name. The first letter "m" will be taken in a short while by the "merge"
> > command for "rebase -i -p", so "message" is out, sadly.
> >
> > But the "rephrase" command will be part of the "rebase -i -p" series when
> > I will finally be able to submit it.
>
> Also, I thought the general plan was to add such features to the
> git-sequencer work which will (hopefully) eventually replace "rebase
> -i". Dscho, can you give a brief update on how that is coming? Are
> rebase patches worth thinking about?
IMHO rebase -i is the important part. The user interface needs some
serious overhaul, which I am in the slow process of doing. The sequencer
then has to follow suit.
As it stands, I think sequencer is not good enough yet to replace rebase
-i (all my comments about that are public, except the heads-up I sent
Stephan in private).
To be frank, 'rebase -i -p' support, as it is in git.git is not good
enough at all. That's why I was working on that, and I am close to
finishing it.
Ciao,
Dscho
^ permalink raw reply
* Re: Local clone checks out wrong branch based on remote HEAD
From: Jeff King @ 2009-03-18 0:54 UTC (permalink / raw)
To: Tom Preston-Werner; +Cc: git
In-Reply-To: <b97024a40903171219k8841508p774d9dc4295a09bc@mail.gmail.com>
On Tue, Mar 17, 2009 at 12:19:35PM -0700, Tom Preston-Werner wrote:
> After cloning this with a standard `git clone`, the refs are:
>
> [11:48][tom@solid:~/dev/sandbox/site(release)]$ git branch -r -v
> origin/HEAD a52528a Fixed some routing problems
> origin/release a52528a Fixed some routing problems
> origin/trunk a52528a Fixed some routing problems
>
> And the checked out branch is 'release' instead of 'trunk' as I would expect:
As others have explained, this is because the information is lacking at
the client and we are forced to make a guess. There is a heuristic in
the guess to prefer "master" if it is an option. I suppose we could make
a similar exception for "trunk", which might make sense to people
working with SVN repositories.
OTOH, I am not sure I want to open the can of worms that is writing an
exhaustive list of heuristics that will work for everybody. Fixing the
protocol itself would probably be easier. :)
Here is what such a heuristic would look like, though (on top of next
and totally untested):
---
diff --git a/remote.c b/remote.c
index 76b1bbd..99d2281 100644
--- a/remote.c
+++ b/remote.c
@@ -1529,11 +1529,18 @@ struct ref *guess_remote_head(const struct ref *head,
if (head->symref)
return copy_ref(find_ref_by_name(refs, head->symref));
- /* If refs/heads/master could be right, it is. */
+ /* We heuristically prefer certain names */
if (!all) {
- r = find_ref_by_name(refs, "refs/heads/master");
- if (r && !hashcmp(r->old_sha1, head->old_sha1))
- return copy_ref(r);
+ const char *rules[] = {
+ "refs/heads/master",
+ "refs/heads/trunk",
+ };
+ int i;
+ for (i = 0; i < ARRAY_SIZE(rules); i++) {
+ r = find_ref_by_name(refs, rules[i]);
+ if (r && !hashcmp(r->old_sha1, head->old_sha1))
+ return copy_ref(r);
+ }
}
/* Look for another ref that points there */
^ permalink raw reply related
* Re: Ability to edit message from git rebase --interactive.
From: Jeff King @ 2009-03-18 0:40 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Olivier Goffart, git
In-Reply-To: <alpine.DEB.1.00.0903172329480.10279@pacific.mpi-cbg.de>
On Tue, Mar 17, 2009 at 11:31:19PM +0100, Johannes Schindelin wrote:
> > I was told on IRC that this has been discussed already not so long ago,
> > and looking on the archive[1], all i seen was bikesheeding . Here is a
> > patch :-)
>
> Unfortunately, the implementation is not the problem, but picking the best
> name. The first letter "m" will be taken in a short while by the "merge"
> command for "rebase -i -p", so "message" is out, sadly.
>
> But the "rephrase" command will be part of the "rebase -i -p" series when
> I will finally be able to submit it.
Also, I thought the general plan was to add such features to the
git-sequencer work which will (hopefully) eventually replace "rebase
-i". Dscho, can you give a brief update on how that is coming? Are
rebase patches worth thinking about?
-Peff
^ permalink raw reply
* [EGIT PATCH 01/25] Use generics for collections in commit dialog and import page
From: Robin Rosenberg @ 2009-03-18 0:40 UTC (permalink / raw)
To: spearce; +Cc: git, Robin Rosenberg
A little cleaner and fewer warnings.
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
.../ui/internal/clone/GitProjectsImportPage.java | 16 ++++++++--------
.../egit/ui/internal/dialogs/CommitDialog.java | 2 +-
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/clone/GitProjectsImportPage.java b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/clone/GitProjectsImportPage.java
index ece585a..5d82edc 100644
--- a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/clone/GitProjectsImportPage.java
+++ b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/clone/GitProjectsImportPage.java
@@ -508,7 +508,7 @@ public void run(IProgressMonitor monitor) {
UIText.WizardProjectsImportPage_SearchingMessage,
100);
selectedProjects = new ProjectRecord[0];
- Collection files = new ArrayList();
+ Collection<File> files = new ArrayList<File>();
monitor.worked(10);
if (directory.isDirectory()) {
@@ -516,14 +516,14 @@ public void run(IProgressMonitor monitor) {
null, monitor)) {
return;
}
- Iterator filesIterator = files.iterator();
+ Iterator<File> filesIterator = files.iterator();
selectedProjects = new ProjectRecord[files.size()];
int index = 0;
monitor.worked(50);
monitor
.subTask(UIText.WizardProjectsImportPage_ProcessingMessage);
while (filesIterator.hasNext()) {
- File file = (File) filesIterator.next();
+ File file = filesIterator.next();
selectedProjects[index] = new ProjectRecord(file);
index++;
}
@@ -562,8 +562,8 @@ setMessage(UIText.WizardProjectsImportPage_projectsInWorkspace,
* The monitor to report to
* @return boolean <code>true</code> if the operation was completed.
*/
- private boolean collectProjectFilesFromDirectory(Collection files,
- File directory, Set directoriesVisited, IProgressMonitor monitor) {
+ private boolean collectProjectFilesFromDirectory(Collection<File> files,
+ File directory, Set<String> directoriesVisited, IProgressMonitor monitor) {
if (monitor.isCanceled()) {
return false;
@@ -577,7 +577,7 @@ private boolean collectProjectFilesFromDirectory(Collection files,
// Initialize recursion guard for recursive symbolic links
if (directoriesVisited == null) {
- directoriesVisited = new HashSet();
+ directoriesVisited = new HashSet<String>();
try {
directoriesVisited.add(directory.getCanonicalPath());
} catch (IOException exception) {
@@ -759,13 +759,13 @@ public CheckboxTreeViewer getProjectsList() {
* workspace
*/
public ProjectRecord[] getValidProjects() {
- List validProjects = new ArrayList();
+ List<ProjectRecord> validProjects = new ArrayList<ProjectRecord>();
for (int i = 0; i < selectedProjects.length; i++) {
if (!isProjectInWorkspace(selectedProjects[i].getProjectName())) {
validProjects.add(selectedProjects[i]);
}
}
- return (ProjectRecord[]) validProjects
+ return validProjects
.toArray(new ProjectRecord[validProjects.size()]);
}
diff --git a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/dialogs/CommitDialog.java b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/dialogs/CommitDialog.java
index b69a4ba..e6bd02d 100644
--- a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/dialogs/CommitDialog.java
+++ b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/dialogs/CommitDialog.java
@@ -366,7 +366,7 @@ public void handleEvent(Event arg0) {
}
try {
ArrayList<GitIndex> changedIndexes = new ArrayList<GitIndex>();
- for (Iterator<Object> it = sel.iterator(); it.hasNext();) {
+ for (Iterator<?> it = sel.iterator(); it.hasNext();) {
CommitItem commitItem = (CommitItem) it.next();
IProject project = commitItem.file.getProject();
--
1.6.1.285.g35d8b
^ permalink raw reply related
* Re: push.default, was Re: What's cooking in git.git (Mar 2009, #04; Sat, 14)
From: Johannes Schindelin @ 2009-03-18 0:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, git
In-Reply-To: <7vab7jpv93.fsf@gitster.siamese.dyndns.org>
Hi,
On Tue, 17 Mar 2009, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Wed, 18 Mar 2009, Nanako Shiraishi wrote:
> >
> >> Quoting Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> >>
> >> > On Sat, 14 Mar 2009, Junio C Hamano wrote:
> >> >
> >> >> * fg/push-default (Wed Mar 11 23:01:45 2009 +0100) 1 commit
> >> >> - New config push.default to decide default behavior for push
> >> >>
> >> >> Replaced the old series with the first step to allow a smooth
> >> >> transition. Some might argue that this should not give any warning
> >> >> but just give users this new configuration to play with first, and
> >> >> after we know we are going to switch default some day, start the
> >> >> warning.
> >> >
> >> > IIRC Steffen posted a patch series earlier, where he initialized
> >> > remote.origin.push upon clone (I am not sure if he provided a
> >> > corresponding patch for checkout --track), but personally, I think
> >> > that would be nicer than having a push.default.
> >>
> >> Isn't recent trend to avoid such inconsistency between behavior in an
> >> existing repository and behavior in a newly created repository? For
> >> example, Jeff calls such inconsistency in
> >>
> >> http://thread.gmane.org/gmane.comp.version-control.git/100339/focus=100433
> >>
> >> as "this breaks in my repo, but when I make a test repo it works".
> >> Junio even called it 'madness' (^_^;)
> >
> > My point is that it is _not_ an inconsistency.
> >
> > It has a default setting. One that already is well established.
> > Push the matching refs.
> >
> > But you can override it by setting the config variable. Which is also
> > well established.
> >
> > The only thing Steffen's patches would have changed would be to set
> > the default differently now.
> >
> > Which is not that much of a 'madness'.
> >
> > Especially if you think about changing the default, which _will_ make
> > for angry users ("why did you change the default? I _liked_ it!
> > Please revert _now_!").
>
> I cloned my old project to my new machine with a recent git and it
> behaves differently. Why did you change the default "git clone"
> creates, without telling me?
>
> Sounds like a huge inconsistency to me.
Okay, I'll bite.
In my git.git clone on one machine, I have remote.orcz.push = master. I
cloned it. There, "git push" does something different.
Inconsistent right there, correct? Without any change to git.git.
Assume push.default goes in.
Nothing changes in my scenario. Inconsistency right there.
Ciao,
Dscho
^ permalink raw reply
* Re: fetch and pull
From: Jeff King @ 2009-03-18 0:37 UTC (permalink / raw)
To: John Dlugosz; +Cc: git, Junio C Hamano
In-Reply-To: <450196A1AAAE4B42A00A8B27A59278E70A3FC0A5@EXCHANGE.trad.tradestation.com>
On Tue, Mar 17, 2009 at 12:44:31PM -0400, John Dlugosz wrote:
> > > You checkout master before updating it?
> >
> > You cannot merge/rebase a branch unless it is checked out.
> >
> Sure you can.
> git rebase upstream topic
This literally does a "checkout" behind the scenes, so it is still
manipulating your working tree. It is basically the equivalent of:
git checkout topic && git rebase upstream
The actual rebasing happens on a detached HEAD, but you will find at the
end of such a rebase that you are now on the branch "topic".
-Peff
^ permalink raw reply
* Re: [JGIT PATCH 3/4] Cap the number of open files in the WindowCache
From: Robin Rosenberg @ 2009-03-18 0:09 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20090317230803.GA23521@spearce.org>
onsdag 18 mars 2009 00:08:03 skrev "Shawn O. Pearce" <spearce@spearce.org>:
> Robin Rosenberg <robin.rosenberg.lists@dewire.com> wrote:
> > tisdag 17 mars 2009 02:16:09 skrev "Shawn O. Pearce" <spearce@spearce.org>:
> >
> > > If we detect a file open failure while opening a pack we halve
> > > the number of permitted open files and try again, [...]
> >
> > The output of getMessage isn't that simple to interpret. Here it is filename+" (Too many files open)",
> > and on other platforms it is probably something else. This goes for the message part of most exceptions
> > thrown from platform specific code like file i/o socket i/o etc. The type of exception is a FileNotFoundException,
> > btw.
> >
> > I wonder whether your code works on any platform.
>
> Arrrgh.
>
> OK. Maybe scrap that part of the patch then?
Yes, I think so, inless you want to try something as ugly as getMessage().toLower().indexof("(too many")? Not
sure what it looks like in Windows or OSX. We know from the JDK source it's filename + "(" + reason +")" and
the problem here is the reason part.
> Its too bad they don't have a specific type of exception for this,
FileNotFoundException is a little more specific. Maybe in combinatikon with a file.exists() and file.canRead test...
(thinking loud now)
> nor do they have a way to hold onto file descriptors under a type
> like a SoftReference where the runtime can whack them if you have
> too many.
The problem is that it's not connected to file descriptors but to memory. Doing a GC on filenotfoundexception
(here) could help here if one uses soft reference, or one could prune the cache manually. The parameter
could also be a
>
> I guess that's why Hadoop HBase just tells you to up your fd ulimit
> to 32767. :-)
Yeah, with gigabytes of memory that might not consume too much resources anyway.
-- robin
^ permalink raw reply
* Re: push.default, was Re: What's cooking in git.git (Mar 2009, #04; Sat, 14)
From: Junio C Hamano @ 2009-03-17 23:47 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Nanako Shiraishi, git
In-Reply-To: <alpine.DEB.1.00.0903172350270.10279@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Wed, 18 Mar 2009, Nanako Shiraishi wrote:
>
>> Quoting Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>>
>> > On Sat, 14 Mar 2009, Junio C Hamano wrote:
>> >
>> >> * fg/push-default (Wed Mar 11 23:01:45 2009 +0100) 1 commit
>> >> - New config push.default to decide default behavior for push
>> >>
>> >> Replaced the old series with the first step to allow a smooth
>> >> transition. Some might argue that this should not give any warning
>> >> but just give users this new configuration to play with first, and
>> >> after we know we are going to switch default some day, start the
>> >> warning.
>> >
>> > IIRC Steffen posted a patch series earlier, where he initialized
>> > remote.origin.push upon clone (I am not sure if he provided a
>> > corresponding patch for checkout --track), but personally, I think
>> > that would be nicer than having a push.default.
>>
>> Isn't recent trend to avoid such inconsistency between behavior in an
>> existing repository and behavior in a newly created repository? For
>> example, Jeff calls such inconsistency in
>>
>> http://thread.gmane.org/gmane.comp.version-control.git/100339/focus=100433
>>
>> as "this breaks in my repo, but when I make a test repo it works". Junio
>> even called it 'madness' (^_^;)
>
> My point is that it is _not_ an inconsistency.
>
> It has a default setting. One that already is well established. Push the
> matching refs.
>
> But you can override it by setting the config variable. Which is also
> well established.
>
> The only thing Steffen's patches would have changed would be to set the
> default differently now.
>
> Which is not that much of a 'madness'.
>
> Especially if you think about changing the default, which _will_ make for
> angry users ("why did you change the default? I _liked_ it! Please
> revert _now_!").
I cloned my old project to my new machine with a recent git and it behaves
differently. Why did you change the default "git clone" creates, without
telling me?
Sounds like a huge inconsistency to me.
^ permalink raw reply
* Re: [PATCH] contrib/difftool: use a separate config namespace for difftool commands
From: Junio C Hamano @ 2009-03-17 23:42 UTC (permalink / raw)
To: markus.heidelberg; +Cc: David Aguilar, Jay Soffian, git
In-Reply-To: <200903172054.46063.markus.heidelberg@web.de>
Markus Heidelberg <markus.heidelberg@web.de> writes:
> David Aguilar, 10.03.2009:
>> On 0, Jay Soffian <jaysoffian@gmail.com> wrote:
>> > On Mon, Mar 9, 2009 at 5:12 AM, David Aguilar <davvid@gmail.com> wrote:
>> > > contrib/difftool/git-difftool | 6 +++---
>> >
>> > Aside, (for Junio I guess...), what's the reason this command is in
>> > contrib, and by what criteria might it graduate to being installed
>> > with the rest of the git commands?
>> >
>> > j.
>>
>> My thoughts (also for Junio, I guess..):
>>
>> If y'all feel that it can live with the rest of the git
>> commands then that would be great =)
>
> I'd like to see it as a general git tool, too.
> Maybe it can even share some common functionality with git-mergetool.
The code was copied and pasted very heavily, and I think (IIRC) the author
was a bit too ashamed to have it outside contrib/ before it is properly
refactored or something like that. Which I happen to agree with, by the
way.
^ permalink raw reply
* Re: Local clone checks out wrong branch based on remote HEAD
From: Junio C Hamano @ 2009-03-17 23:40 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Tom Preston-Werner, git
In-Reply-To: <alpine.LNX.1.00.0903171530160.19665@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> ... I think there's also been discussion of a
> protocol extension to transmit the information, although I don't know
> where that ended up.
You can find them in the list of threads posted nearby.
The first round's protocol extension was not quite backward compatible
but in a benign way, in that it did not break anything but induced a
harmless warning from older ls-remote. The second round did not have such
flaw but it got a "Yuck".
From: Jeff King <peff@peff.net>
Date: Mon, 1 Dec 2008 12:44:15 -0500
Message-ID: <20081201174414.GA22185@coredump.intra.peff.net>
Subject: Re: [PATCH 5/6 (v2)] upload-pack: send the HEAD information
I somehow feel that the "Yuck" was addressed not to the patches but to the
problem the patch needs to address.
We could resurrect it if somebody is interested.
^ permalink raw reply
* [PATCH] git config: clarify bool types
From: Felipe Contreras @ 2009-03-17 23:13 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin, Junio C Hamano, Felipe Contreras
The value is what it is, the --bool and --bool-or-int options don't
specify the value type, just how it is interpreted. For example: a value
of '1' can be interpreted as 'true'.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
This applies on top of the 'next' branch.
builtin-config.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin-config.c b/builtin-config.c
index 1a3baa1..c3a0176 100644
--- a/builtin-config.c
+++ b/builtin-config.c
@@ -66,9 +66,9 @@ static struct option builtin_config_options[] = {
OPT_STRING(0, "get-color", &get_color_slot, "slot", "find the color configured: [default]"),
OPT_STRING(0, "get-colorbool", &get_colorbool_slot, "slot", "find the color setting: [stdout-is-tty]"),
OPT_GROUP("Type"),
- OPT_BIT(0, "bool", &types, "value is \"true\" or \"false\"", TYPE_BOOL),
+ OPT_BIT(0, "bool", &types, "value is intepreted as bool (\"true\" or \"false\")", TYPE_BOOL),
OPT_BIT(0, "int", &types, "value is decimal number", TYPE_INT),
- OPT_BIT(0, "bool-or-int", &types, "value is --bool or --int", TYPE_BOOL_OR_INT),
+ OPT_BIT(0, "bool-or-int", &types, "value is interpreted either as bool or int", TYPE_BOOL_OR_INT),
OPT_GROUP("Other"),
OPT_BOOLEAN('z', "null", &end_null, "terminate values with NUL byte"),
OPT_END(),
--
1.6.2.313.g33352
^ permalink raw reply related
* Re: [JGIT PATCH 3/4] Cap the number of open files in the WindowCache
From: Shawn O. Pearce @ 2009-03-17 23:08 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <200903172359.32595.robin.rosenberg.lists@dewire.com>
Robin Rosenberg <robin.rosenberg.lists@dewire.com> wrote:
> tisdag 17 mars 2009 02:16:09 skrev "Shawn O. Pearce" <spearce@spearce.org>:
>
> > If we detect a file open failure while opening a pack we halve
> > the number of permitted open files and try again, [...]
>
> The output of getMessage isn't that simple to interpret. Here it is filename+" (Too many files open)",
> and on other platforms it is probably something else. This goes for the message part of most exceptions
> thrown from platform specific code like file i/o socket i/o etc. The type of exception is a FileNotFoundException,
> btw.
>
> I wonder whether your code works on any platform.
Arrrgh.
OK. Maybe scrap that part of the patch then?
Its too bad they don't have a specific type of exception for this,
nor do they have a way to hold onto file descriptors under a type
like a SoftReference where the runtime can whack them if you have
too many.
I guess that's why Hadoop HBase just tells you to up your fd ulimit
to 32767. :-)
--
Shawn.
^ permalink raw reply
* Re: [JGIT PATCH 3/4] Cap the number of open files in the WindowCache
From: Robin Rosenberg @ 2009-03-17 22:59 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <1237252570-8596-4-git-send-email-spearce@spearce.org>
tisdag 17 mars 2009 02:16:09 skrev "Shawn O. Pearce" <spearce@spearce.org>:
> If we detect a file open failure while opening a pack we halve
> the number of permitted open files and try again, until we reach
> a lower bound of 16 open files. Needing to go lower may indicate
> a file descriptor leak in the host application.
...
> + TRY_OPEN: for (;;) {
> + try {
> + openFileCount++;
> + releaseMemory();
> + runClearedWindowQueue();
> + wp.openCount = 1;
> + wp.cacheOpen();
> + break;
> + } catch (IOException ioe) {
> + openFileCount--;
> + if ("Too many open files".equals(ioe.getMessage())
> + && maxFileCount > 16) {
The output of getMessage isn't that simple to interpret. Here it is filename+" (Too many files open)",
and on other platforms it is probably something else. This goes for the message part of most exceptions
thrown from platform specific code like file i/o socket i/o etc. The type of exception is a FileNotFoundException,
btw.
I wonder whether your code works on any platform.
^ permalink raw reply
* Re: push.default, was Re: What's cooking in git.git (Mar 2009, #04; Sat, 14)
From: Johannes Schindelin @ 2009-03-17 22:53 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git, Junio C Hamano
In-Reply-To: <20090318063053.6117@nanako3.lavabit.com>
Hi,
On Wed, 18 Mar 2009, Nanako Shiraishi wrote:
> Quoting Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>
> > On Sat, 14 Mar 2009, Junio C Hamano wrote:
> >
> >> * fg/push-default (Wed Mar 11 23:01:45 2009 +0100) 1 commit
> >> - New config push.default to decide default behavior for push
> >>
> >> Replaced the old series with the first step to allow a smooth
> >> transition. Some might argue that this should not give any warning
> >> but just give users this new configuration to play with first, and
> >> after we know we are going to switch default some day, start the
> >> warning.
> >
> > IIRC Steffen posted a patch series earlier, where he initialized
> > remote.origin.push upon clone (I am not sure if he provided a
> > corresponding patch for checkout --track), but personally, I think
> > that would be nicer than having a push.default.
>
> Isn't recent trend to avoid such inconsistency between behavior in an
> existing repository and behavior in a newly created repository? For
> example, Jeff calls such inconsistency in
>
> http://thread.gmane.org/gmane.comp.version-control.git/100339/focus=100433
>
> as "this breaks in my repo, but when I make a test repo it works". Junio
> even called it 'madness' (^_^;)
My point is that it is _not_ an inconsistency.
It has a default setting. One that already is well established. Push the
matching refs.
But you can override it by setting the config variable. Which is also
well established.
The only thing Steffen's patches would have changed would be to set the
default differently now.
Which is not that much of a 'madness'.
Especially if you think about changing the default, which _will_ make for
angry users ("why did you change the default? I _liked_ it! Please
revert _now_!").
Ciao,
Dscho
^ permalink raw reply
* Re: Ability to edit message from git rebase --interactive.
From: Johannes Schindelin @ 2009-03-17 22:31 UTC (permalink / raw)
To: Olivier Goffart; +Cc: git
In-Reply-To: <200903171953.23650.ogoffart@kde.org>
Hi,
On Tue, 17 Mar 2009, Olivier Goffart wrote:
> I use git in a workflow in wich we often need to edit the message logs
> of some commits. The way we do it is using git rebase -i and choose
> edit. But then you need to do git commit --amend and git rebase
> --continue, which is error prone and add more useless steps.
>
> The attached patch add a new keyword to git rebase interactive to just
> edit the message log.
>
> I was told on IRC that this has been discussed already not so long ago,
> and looking on the archive[1], all i seen was bikesheeding . Here is a
> patch :-)
Unfortunately, the implementation is not the problem, but picking the best
name. The first letter "m" will be taken in a short while by the "merge"
command for "rebase -i -p", so "message" is out, sadly.
But the "rephrase" command will be part of the "rebase -i -p" series when
I will finally be able to submit it.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] builtin-tag.c: remove global variable to use the callback data of git-config.
From: Johannes Schindelin @ 2009-03-17 22:27 UTC (permalink / raw)
To: Carlos Rica; +Cc: gitster, git
In-Reply-To: <1b46aba20903171057r4fb4697eo3b8abc62a45fe858@mail.gmail.com>
Hi,
On Tue, 17 Mar 2009, Carlos Rica wrote:
> On Tue, Mar 17, 2009 at 4:47 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> > Hi,
> > On Tue, 17 Mar 2009, Carlos Rica wrote:
> >> @@ -164,11 +162,10 @@ static int do_sign(struct strbuf *buffer)
> >> int len;
> >> int i, j;
> >>
> >> - if (!*signingkey) {
> >> - if (strlcpy(signingkey, git_committer_info(IDENT_ERROR_ON_NO_NAME),
> >> - sizeof(signingkey)) > sizeof(signingkey) - 1)
> >> - return error("committer info too long.");
> >> - bracket = strchr(signingkey, '>');
> >> + if (!signingkey->buf[0]) {
> >
> > It is probably better to ask for !signingkey->len (think of trying to
> > understand the code in 6 months from now).
>
> I was in doubt here. By avoiding the use of signingkey->len I was
> trying to say that you cannot rely in such field if we touch the
> buffer directly, as it happens below:
>
> bracket = strchr(signingkey->buf, '>');
> if (bracket)
> bracket[1] = '\0';
Oh, I missed that. It should read
if (bracket)
strbuf_setlen(signingkey, bracket + 1 - signingkey->buf);
instead.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Define a version of lstat(2) specially for copy operation
From: Alex Riesen @ 2009-03-17 21:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, Jeff King, layer, git
In-Reply-To: <7v63i7ridk.fsf@gitster.siamese.dyndns.org>
So that Cygwin port can continue work around its supporting
library and get access to its faked file attributes.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
Junio C Hamano, Tue, Mar 17, 2009 21:42:31 +0100:
> But isn't this something shops that do deploy Cygwin version of git want
> to see fixed, so that they can have a site-wide policy implemented in the
Frankly, I doubt they know or care.
> hooks copied from templates? I think we could pass mode 0 to copy_files()
> and have the function special case it (and allow a platform specific
> copy_files() implementated by Cygwin). lstat() in the copy_templates_1()
> codepath is primarily done to see if we need to descend into a directory
> or symlink() and our use of st.st_mode to pass to copy_files() is a no
> cost side effect on platforms with x-bit support.
And I don't think that the platform broken in so many ways deserves
that kind of treatement. Maybe this patch is enough. Will test it
tomorrow, when I get to mine so much hated Windows system.
> >> access(..., X_OK), not lstat(). We don't play games with access(), do we?
> > access(..., X_OK) will return -1.
>
> That codepath would also need to be fixed if Cygwin wants to use hooks, I
> would guess.
I hope not. In the reply to Johannes' example I was referring to the
copied file, the one which was created with open(..., O_CREAT..., 0666),
0666 being there because of our lstat stub.
builtin-init-db.c | 2 +-
git-compat-util.h | 5 +++++
2 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/builtin-init-db.c b/builtin-init-db.c
index ee3911f..f3f781b 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -66,7 +66,7 @@ static void copy_templates_1(char *path, int baselen,
else
exists = 1;
- if (lstat(template, &st_template))
+ if (lstat_for_copy(template, &st_template))
die("cannot stat template %s", template);
if (S_ISDIR(st_template.st_mode)) {
diff --git a/git-compat-util.h b/git-compat-util.h
index 878d83d..4c23478 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -85,11 +85,16 @@
#undef _XOPEN_SOURCE
#include <grp.h>
#define _XOPEN_SOURCE 600
+static inline int lstat_for_copy(const char *file_name, struct stat *buf)
+{
+ return lstat(file_name, buf);
+}
#include "compat/cygwin.h"
#else
#undef _ALL_SOURCE /* AIX 5.3L defines a struct list with _ALL_SOURCE. */
#include <grp.h>
#define _ALL_SOURCE 1
+#define lstat_for_copy lstat
#endif
#else /* __MINGW32__ */
/* pull in Windows compatibility stuff */
--
1.6.2.1.171.g3422
^ permalink raw reply related
* Local clone checks out wrong branch based on remote HEAD
From: Nanako Shiraishi @ 2009-03-17 21:31 UTC (permalink / raw)
To: Tom Preston-Werner; +Cc: git
In-Reply-To: <b97024a40903171219k8841508p774d9dc4295a09bc@mail.gmail.com>
Quoting Tom Preston-Werner <tom@github.com>:
> I'm guessing that the first branch that matches the remote HEAD
> revision is being checked out instead of the actual remote branch. I
> would expect the correct branch to be chosen regardless of where the
> branches are pointing.
Isn't this a known issue that can be found out easily from the archive?
http://article.gmane.org/gmane.comp.version-control.git/27259
http://thread.gmane.org/gmane.comp.version-control.git/101956/focus=101958
http://thread.gmane.org/gmane.comp.version-control.git/102039
If I remember correctly, the two patch series from Junio wasn't accepted warmly and they were dropped.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: fetch and pull
From: Nanako Shiraishi @ 2009-03-17 21:31 UTC (permalink / raw)
To: John Dlugosz; +Cc: git, Junio C Hamano
In-Reply-To: <450196A1AAAE4B42A00A8B27A59278E70A3FC0A5@EXCHANGE.trad.tradestation.com>
Quoting John Dlugosz <JDlugosz@TradeStation.com>:
> My concern is that you establish your working state based on the local 'master', only to immediately change it again when the pull updates master. But that's the way it's supposed to work?
>
> I think the documentation for git-pull might also be garbled from text being of different eras. "Normally the branch merged is the HEAD of the remote"? That will be basically random since the last thing the upstream repo user did will control what his HEAD is.
That's how it's supposed to work, and the documentation isn't from a different era, either. Majority of users clone from a central repository and keep pulling to update their clones, and in that kind of setting, HEAD will never change. A HEAD in a bare repository tells people which branch is the primary branch of the project.
I think you are confused because you are thinking that it's typical to pull from a live repository that has a working tree somebody else uses to grow his history, and you are correct that you can't predict which branch HEAD points at at any given moment. But that isn't how a typical workflow uses pull and push between repositories.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* push.default, was Re: What's cooking in git.git (Mar 2009, #04; Sat, 14)
From: Nanako Shiraishi @ 2009-03-17 21:30 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.0903171125420.6393@intel-tinevez-2-302>
Quoting Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> On Sat, 14 Mar 2009, Junio C Hamano wrote:
>
>> * fg/push-default (Wed Mar 11 23:01:45 2009 +0100) 1 commit
>> - New config push.default to decide default behavior for push
>>
>> Replaced the old series with the first step to allow a smooth
>> transition. Some might argue that this should not give any warning but
>> just give users this new configuration to play with first, and after we
>> know we are going to switch default some day, start the warning.
>
> IIRC Steffen posted a patch series earlier, where he initialized
> remote.origin.push upon clone (I am not sure if he provided a
> corresponding patch for checkout --track), but personally, I think that
> would be nicer than having a push.default.
Isn't recent trend to avoid such inconsistency between behavior in an existing repository and behavior in a newly created repository? For example, Jeff calls such inconsistency in
http://thread.gmane.org/gmane.comp.version-control.git/100339/focus=100433
as "this breaks in my repo, but when I make a test repo it works". Junio even called it 'madness' (^_^;)
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ 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