* Advice/help needed
From: Ian Hobson @ 2009-11-16 16:27 UTC (permalink / raw)
To: git
Hi all,
I am trying to switch to GIT (from SVN), and have become sorely
confused. I am not sure of the best way to solve the problem I have,
(nor how to actually implement a solution when one is chosen).
I am building a web application in php. There are 2 (soon to be four)
versions each slightly different for different customers. Each needs
testing when installed in "/" and "/dir" on the web site.
So far I have one system that in installed in a git repo on a Linux VM
with a share. This way I can develop in windows where I am familiar,
serve the files under linux (to match the production environment) and
run unit tests using phpUnit. The test files are all in a sub-directory
of the main directory. The application is served from a directory in the
website, so I could have different directories for different purposes,
but I have not had to use this yet.
Before release, I fetch and merge the files into a second installation
under windows, where I can serve it from the root. This forms a second
level of test. I release by copying the files with FTP (so that test
files and the GIT repo don't go on the production server).
This arrangement only works because I have been able to set up the
configuration files, database users and similar so they are all the same
on each installation. With 4 similar versions this will no longer be
possible.
What I want to be able to do is control all 4 versions in the same
manner, keep all file - common, different and test - in git, and have
checkout worry about changing versions.
My thoughts are to have 4 branches, one for each customer. 99% of all
changes will be needed by all (or at least most)
of the customers (P,W,S and E). How can I make a change to master and
then use git to apply those changes to the four branches, without losing
the differences between branches?
For example (if this is the best way) go from this
O-----O-----A-----B-----C (master)
\----P
\---W
\--S
\-E
to first this, where D is the net effect of A B and C (this is for ease
of reading logs, and commit messages),
O-----O-----D (head)
\----P
\---W
\--S
\-E
and then to this, (without editing all the files four times?)
O-----O-----D (head)
\----P-----D'
\---W----D''
\--S-----D'''
\-E-----D''''
Or would I be better having 4 repositories, one for each customer? Then
I need to pull changes and cherry pick the changes I want for each
customer?
I am the only developer, so the processes need to be simple so I am not
faced with sorting out my own errors! :)
Regards
Ian
^ permalink raw reply
* Re: Advice/help needed
From: Yann Simon @ 2009-11-16 16:40 UTC (permalink / raw)
To: Ian Hobson; +Cc: git
In-Reply-To: <4B017D77.6060505@ianhobson.co.uk>
2009/11/16 Ian Hobson <ian@ianhobson.co.uk>:
> My thoughts are to have 4 branches, one for each customer. 99% of all
> changes will be needed by all (or at least most)
> of the customers (P,W,S and E). How can I make a change to master and then
> use git to apply those changes to the four branches, without losing the
> differences between branches?
>
> For example (if this is the best way) go from this
> O-----O-----A-----B-----C (master)
> \----P
> \---W
> \--S
> \-E
>
> to first this, where D is the net effect of A B and C (this is for ease of
> reading logs, and commit messages),
> O-----O-----D (head) \----P
> \---W
> \--S
> \-E
>
> and then to this, (without editing all the files four times?)
> O-----O-----D (head)
> \----P-----D'
> \---W----D''
> \--S-----D'''
> \-E-----D''''
What I would do is:
- one branch for the common
- one branch for each customer, which contains the specific
differences compare to the common branch
You could program on the common branch.
When you are ready, you can checkout each specific branch and rebase
on the common branch.
For example:
$ git checkout common
edit, test, commit
$ git checkout client1
$ git rebase common
$ git checkout client2
$ git rebase common
Another solution is to have a branch for each customer, to commit on
one branch, and to cherry-pick this last commit on all the other
branches.
Yann
^ permalink raw reply
* Re: [PATCH] RFC Allow case insensitive search flag with git-grep for fixed-strings
From: Brian Collins @ 2009-11-16 16:58 UTC (permalink / raw)
To: Jeff King; +Cc: Nanako Shiraishi, Junio C Hamano, git
In-Reply-To: <20091116162533.GA30737@coredump.intra.peff.net>
> 1. The patch was line-wrapped; I had to de-munge it manually to apply.
Ugh, does gmail do this? Sorry
> 3. No signed-off-by. Brian, can you please acknowledge the DCO with a
> signoff?
Signed-off-by: Brian Collins <bricollins@gmail.com>
> 4. The patch introduced some stray trailing whitespace.
>
> 5. There were a few style fixups, like omitting braces for a
> single-line conditional.
Again sorry, thought the opposite was in the style guide.
--
Brian Collins
^ permalink raw reply
* Re: [PATCH] gitweb: Support for no project list on gitweb front page
From: Petr Baudis @ 2009-11-16 17:52 UTC (permalink / raw)
To: J.H.; +Cc: git
In-Reply-To: <4AF472E5.1000602@eaglescrag.net>
On Fri, Nov 06, 2009 at 11:03:01AM -0800, J.H. wrote:
> Petr Baudis wrote:
> >On very large sites like repo.or.cz (but maybe also git.debian.org,
> >git.kernel.org, etc.),
>
> I think between our own caching (which I'll be submitting a cleaned
> up patch for here shortly for mainline inclusion) and our users want
> to *NOT* deal with searching or pagination this actually isn't that
> useful to us, despite having a signifigant number of projects, and
> the front page (at leas for us) only weighing in at 567,710bytes
> means that we are moving less data to show the git.kernel.org page
> than facebook does to show their home screen (I.E. anything modern
> can trivially cope with that)
Sure, you still have much fewer projects than repo.or.cz. :-)
Perhaps others will still find it useful.
> >it is desirable not to have the project list
> >on the front page since generating it is significant overhead and it
> >takes significant data transfer and load time for the user, who might
> >prefer to instead use the search form and possibly content tags to
> >navigate to the target project. A link to the full list of projects is
> >still available on the front page for users who wish to browse it. The
> >whole feature is turned off by default.
> >
> >The patch introduces a new config variable $frontpage_no_project_list,
> >by default 0 keeping the current behavior; if set to 1, no project list
> >will be shown, but all projects will be still scanned if ctags are
> >enabled; if set to 2, no project will be shown and no projects will
> >be scanned while showing the front page. The compromise value of 1 is
> >useful for sites where project scan time is not an issue or which
> >use additional project list caching patches.
>
> I question the need for 0,1,2. If the site doesn't want something
> like the tag cloud they are already going to turn it off with the
> normal cloud system. I think this should be either a bitmask or an
> array to explicitly turn particular things on or off, or a binary
> value that would *ONLY* deal with showing the project listing.
I have no problem with either way, 2 seemed useful so that people can
continue to use ctags but have the front page without any project
scanning whatsoever, but if people think it makes no sense to have it,
I can drop it. I will resend the patch with this being a bitmask
instead, though.
--
Petr "Pasky" Baudis
A lot of people have my books on their bookshelves.
That's the problem, they need to read them. -- Don Knuth
^ permalink raw reply
* Re: [PATCH] gitweb: Refactor project list routines
From: Petr Baudis @ 2009-11-16 17:56 UTC (permalink / raw)
To: J.H.; +Cc: git
In-Reply-To: <4AF47142.4010609@eaglescrag.net>
Hi!
On Fri, Nov 06, 2009 at 10:56:02AM -0800, J.H. wrote:
> 2) If the repository is cloned the ctag information is not retained,
> which means there is no real way for the original developer to
> manage or move this information between different hosting sites,
> I.E. repo.or.cz and kernel.org (though I'll admit I have it turned
> off)
This is interesting argument, I have always thought about ctags being
a rather site-specific mechanism and I think it would've meet with a lot
of user opposition to e.g. keep ctags in a specific branch; I can think
of no other good way to do it either.
> So if your going to eliminate the project listing, with the general
> intention of using the tag cloud as more of a primary search
> mechanism, including the search box, I think there's some serious
> work that needs to be put into the ctags system because in it's
> current state, for the likes of kernel.org, it's unusable, unstable
> and not something I would recommend to anyone to run in production.
> I like the idea, I just have concerns over it's current
> implementation.
This patch is orthogonal to that, I believe. I agree that the ctags
mechanism is somewhat hackish; unfortunately, I personally don't have
the time to fix it up properly. I think it is still good enough for
many users, and the frontpage mechanism would be quite useful even for
people who don't want to use content tags.
--
Petr "Pasky" Baudis
A lot of people have my books on their bookshelves.
That's the problem, they need to read them. -- Don Knuth
^ permalink raw reply
* Re: [PATCH] RFC Allow case insensitive search flag with git-grep for fixed-strings
From: Brandon Casey @ 2009-11-16 18:00 UTC (permalink / raw)
To: Brian Collins; +Cc: Jeff King, Nanako Shiraishi, Junio C Hamano, git
In-Reply-To: <d1c0fbfa0911160858k2cdd35bfvf27df2a5c97348ad@mail.gmail.com>
Brian Collins wrote:
>> 1. The patch was line-wrapped; I had to de-munge it manually to apply.
>
> Ugh, does gmail do this?
In my experience, yes.
There's a section in Documentation/SubmittingPatches about using the imap
interface to upload patches into gmail's "Drafts" folder. SubmittingPatches
then says to "Go to your Gmail account, open the Drafts folder, and find the
patch email, fill in the To: and CC: fields and send away". I tried that
once and the gmail web interface still introduced new lines. Either I'm doing
something wrong, or that document should be changed to clarify that the web
interface cannot be used even if the patch is uploaded to the Drafts folder
via imap.
-brandon
^ permalink raw reply
* git multisite setup
From: Matt Di Pasquale @ 2009-11-16 18:18 UTC (permalink / raw)
To: git
Hi,
In my sites folder i have folders for different sites of mine:
example.com example2.com, and i also have generic files like an
includes dir and a .htaccess file that all sites use. what is the best
way to track the generic files and the different sites?
i was thinking each site has its own .git repo. and then make a .git
repo for my sites folder but ignore the individual sites dirs.
actually that's what i'm doing now.
should i use submodules? i don't really understand submodules and the
examples i saw did not cover nested folders
Thanks!
matt
^ permalink raw reply
* Re: [PATCH 3/3] rebase: refuse to rebase with -s ours
From: Junio C Hamano @ 2009-11-16 19:57 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Thomas Rast, git, Nicolas Sebrecht, Baz, Peter Krefting,
Björn Steinbrink
In-Reply-To: <alpine.DEB.1.00.0911161333470.4985@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Sun, 15 Nov 2009, Thomas Rast wrote:
>
>> Using the "ours" strategy with rebase just discards all changes, turning
>> <branch> into <upstream> (or <newbase> if given). This is unlikely to
>> be what the user wants, so simply refuse to do it.
>
> "Unlikely" or "impossible"?
It is more like "very likely to be a mistake".
Our tradition has been to give them long enough rope, but the recent trend
is to consider ourselves experienced enough with various git workflows to
be capable of identifying not just "cannot possibly a meaningful request"
but also "almost always a mistake" cases, and tighten the rope to help
people from stumbling, I think.
But it needs more careful thought to avoid forbidding useful use cases,
and your input is hugely appreciated if you have doubts (even better, an
example of useful use case that will become impossible).
> Besides, I find it rather arbitrary that the "ours" strategy is refused,
> but none of the user-provided merge strategies. IOW disallowing "ours"
> may very well foster unreasonable expectations.
I cannot read this quite clearly. Unreasonable expectations being...?
* "ours" is disallowed but anything else including user-provided ones are
Ok, so we are allowed to circumvent this restriction by adding a
synonym for "ours" as a user-defined one, and are encouraged to do
so. ---that is a wrong message to send. Is that what you mean?
* strategy X, unlike "ours", is allowed, so users will have rights to
expect use of X as a rebase strategy would yield useful result, but
that is wrong---Dscho knows that merge strategy X (I cannot read which
one you had in mind if this is what you are talking about) does not
work well in this and that cases. Is this what you mean, and if so
what is X?
Perhaps you had something other than the above two in mind?
^ permalink raw reply
* Re: pushing remote branches
From: Junio C Hamano @ 2009-11-16 20:05 UTC (permalink / raw)
To: Lorenzo Bettini; +Cc: git
In-Reply-To: <hdrr1e$oub$1@ger.gmane.org>
Lorenzo Bettini <bettini@dsi.unifi.it> writes:
>> Anyway to answer your question, I do not see the refspec line as the issue
>> here, but the URL for the repo, which determines how you access it.
>
> so this would have been enough:
>
>>> [remote "origin"]
>>> fetch = +refs/heads/*:refs/remotes/origin/*
>>> url = git://...
>>> [branch "master"]
>>> remote = origin
>>> merge = refs/heads/master
>>> [branch "experiments"]
>>> remote = origin
>>> merge = refs/heads/experiments
Because "git://" is almost always read-only, you wouldn't be able to push
back to the origin with that configuration. If you are only following the
project that is perfectly fine.
Otherwise, either use "git@..." in remote.origin.url to use git-over-ssh
in both directions, or you can use pushurl if you have recent enough
version of git, like:
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
url = git://...
pushurl = git@...
When you primed your repository with "git clone git://...", it would be
nice if "clone" added a "corresponding" pushurl for you. But ... part of
the two lines are often different, depending on how hosting site is
organized, so unfortunately "clone" cannot do so.
^ permalink raw reply
* Re: [PATCH 2/2] diffcore-break: save cnt_data for other phases
From: Junio C Hamano @ 2009-11-16 21:20 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20091116160202.GB30777@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> The "break" phase works by counting changes between two
> blobs with the same path. We do this by splitting the file
> into chunks (or lines for text oriented files) and then
> keeping a count of chunk hashes.
>
> The "rename" phase counts changes between blobs at two
> different paths. However, it uses the exact same set of
> chunk hashes (which are immutable for a given sha1).
>
> The rename phase can therefore use the same hash data as
> break. Unfortunately, we were throwing this data away after
> computing it in the break phase. This patch instead attaches
> it to the filespec and lets it live through the rename
> phase, working under the assumption that most of the time
> that breaks are being computed, renames will be too.
The change looks correct, but I initially got worried about your change
interacts badly with this part in estimate_similarity() around line 176:
if (!src->cnt_data && diff_populate_filespec(src, 0))
return 0;
if (!dst->cnt_data && diff_populate_filespec(dst, 0))
return 0;
I think the reason why it (not your patch but the original code) felt a
bit brittle is because the above if() statements know too much about the
internal of d-c-c (namely, it never looks at src->data when src->cnt_data
is already available, so it is safe to leave src->data NULL).
The same logic suggests that the loop to build the matrix in
diffcore_rename() could free two->data at the end of the innermost loop.
We currently loop this way (around ll. 505-530):
for each two (i.e. rename destination candidate):
for each one (i.e. rename source candidate):
compute and record how similar one and two are
free one->data
free two->data
After computing how similar "one" and something else is only once, we have
one->cnt_data so we won't need one->data (the same fact is exploited by
your patch for optimization), and that is why freeing one->data in the
innermost loop does not result in constant re-reading of the same blob
data when we iterate more than one rename destination. But the same logic
applies to "two" and we should be able to free the blob data early to
reduce the memory pressure.
I dunno if it would give us measurable performance benefit, though.
Here is the idea on top of your patch, but I think it can be applied
independently.
diffcore-rename.c | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/diffcore-rename.c b/diffcore-rename.c
index 63ac998..875ca81 100644
--- a/diffcore-rename.c
+++ b/diffcore-rename.c
@@ -523,10 +523,13 @@ void diffcore_rename(struct diff_options *options)
this_src.dst = i;
this_src.src = j;
record_if_better(m, &this_src);
+ /*
+ * Once we run estimate_similarity,
+ * We do not need the text anymore.
+ */
diff_free_filespec_blob(one);
+ diff_free_filespec_blob(two);
}
- /* We do not need the text anymore */
- diff_free_filespec_blob(two);
dst_cnt++;
}
^ permalink raw reply related
* Re: [PATCH 3/3] rebase: refuse to rebase with -s ours
From: Johannes Schindelin @ 2009-11-16 21:25 UTC (permalink / raw)
To: Junio C Hamano
Cc: Thomas Rast, git, Nicolas Sebrecht, Baz, Peter Krefting,
Björn Steinbrink
In-Reply-To: <7vpr7ip7ji.fsf@alter.siamese.dyndns.org>
Hi,
On Mon, 16 Nov 2009, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Sun, 15 Nov 2009, Thomas Rast wrote:
> >
> >> Using the "ours" strategy with rebase just discards all changes,
> >> turning <branch> into <upstream> (or <newbase> if given). This is
> >> unlikely to be what the user wants, so simply refuse to do it.
>
> > Besides, I find it rather arbitrary that the "ours" strategy is
> > refused, but none of the user-provided merge strategies. IOW
> > disallowing "ours" may very well foster unreasonable expectations.
>
> I cannot read this quite clearly.
I meant the following: if "rebase -s ours" refuses to run, but my boss has
written this cunning merge strategy "superduper" which is equally unlikely
to yield a sensible result, "rebase -s superduper" should still refuse to
run, no?
Now, this scenario might be too rare to take care of, but maybe it shows
that we have a design flaw here?
Ciao,
Dscho
P.S.: Please note that I do not make a case against Thomas' patch series.
As gitzilla once said "I cannot provide alternative patches, so that's
that".
^ permalink raw reply
* Re: [PATCH 3/3] rebase: refuse to rebase with -s ours
From: Junio C Hamano @ 2009-11-16 21:45 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Thomas Rast, git, Nicolas Sebrecht, Baz, Peter Krefting,
Björn Steinbrink
In-Reply-To: <alpine.DEB.1.00.0911162213590.4985@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> I meant the following: if "rebase -s ours" refuses to run, but my boss has
> written this cunning merge strategy "superduper" which is equally unlikely
> to yield a sensible result, "rebase -s superduper" should still refuse to
> run, no?
Why should it?
> Now, this scenario might be too rare to take care of, but maybe it shows
> that we have a design flaw here?
The decision is up to the user who is much more familiar with such a
custom 'superduper' strategy, and git itself is in no position to make
that decision for the user. It is none of our business to forbid users
from using what he wrote, when we do not know what it is.
I do not think the "rarity" is relevant.
What do you mean by a design flaw? In other words, how should things look
like in your ideal design?
Certainly you are not talking about a design that enforces users who want
to use custom strategy to first submit the strategy implementation to us
for a review and have our blessings (perhaps we digitally sign approved
strategy implementations) before being able to use it in "merge -s" and
"rebase -s".
I can _guess_ what you are _not_ talking about but I cannot tell what you
_are_ talking about; sorry.
^ permalink raw reply
* Manipulating existing revisions by push or pull?
From: Lasse Kliemann @ 2009-11-16 21:49 UTC (permalink / raw)
To: git
I've got a conceptual question.
I know that one can change history in a local repository with the
'rebase' command, e.g., using the interactive mode.
Is there any way to modify existing revisions in a local
repository by a pull (and merge, whatever) from a remote one? Or
is there any way to modify existing revisions in a remote
repository by a push (or whatever) from a local one?
Put a different way: consider there is a hostile entity from
which I pull or which I allow to push to me. Can this entity
fiddle with my history? Can it change the data in existing
revisions in my repository? Or can it only make new revisions
grow on my side?
Thank you
Lasse
^ permalink raw reply
* Re: Manipulating existing revisions by push or pull?
From: Junio C Hamano @ 2009-11-16 21:53 UTC (permalink / raw)
To: Lasse Kliemann; +Cc: git
In-Reply-To: <hdshcm$c06$1@ger.gmane.org>
"Lasse Kliemann" <lasse-gmane-git-2009@mail.plastictree.net> writes:
> Put a different way: consider there is a hostile entity from
> which I pull or which I allow to push to me. Can this entity
> fiddle with my history? Can it change the data in existing
> revisions in my repository? Or can it only make new revisions
> grow on my side?
If you allow your ref to get updated to an arbitrary value, you are lost,
unless you have signed tags that anchor things in place, in which case you
can trust the part of history that is reachable from them.
^ permalink raw reply
* Re: [PATCH 3/3] rebase: refuse to rebase with -s ours
From: Sverre Rabbelier @ 2009-11-16 22:04 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Thomas Rast, git, Nicolas Sebrecht, Baz,
Peter Krefting, Björn Steinbrink
In-Reply-To: <7viqdannxo.fsf@alter.siamese.dyndns.org>
Heya,
On Mon, Nov 16, 2009 at 22:45, Junio C Hamano <gitster@pobox.com> wrote:
> I can _guess_ what you are _not_ talking about but I cannot tell what you
> _are_ talking about; sorry.
I would hazard a way for the merge strategy to indicate whether it is
fit to be used as rebase strategy?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* serf causing "temp file with moniker 'svn_delta' already in use"?
From: Blair Zajac @ 2009-11-16 21:55 UTC (permalink / raw)
To: git
I've seen some reports of the following error using git svn and encountered it
myself with git 1.6.5.2 with Subversion 1.6.5:
Temp file with moniker 'svn_delta' already in use at
/opt/local/lib/perl5/site_perl/5.8.9/Git.pm line 1022.
In Googling around I seen other people discussing the issue but with no real
root cause.
I'm guessing that it may be due to an API violation of the Subversion RA editors
when Serf is used:
http://subversion.tigris.org/issues/show_bug.cgi?id=2932
http://n2.nabble.com/git-svn-fails-to-fetch-repository-td2151475.html
I can generate the above error on demand with Serf but if I switch to Neon then
everything works fine. People may be using Serf because they compiled
Subversion with Serf and without Neon or instructed Subversion to use Serf
instead by this setting in their ~/.subversion/servers:
[global]
http-library = serf
I haven't looked at this issue beyond being able to reproduce it with Serf and
without Neon, but hope this gives some direction to the issue.
This bug may get fixed in Subversion as we want to move to Serf as the default
HTTP client away from Neon and this is one of the outstanding issues before
making that switch.
Regards,
Blair
^ permalink raw reply
* Re: Advice/help needed
From: Ian Hobson @ 2009-11-16 22:46 UTC (permalink / raw)
To: Yann Simon; +Cc: git
In-Reply-To: <551f769b0911160840k6ea274e9q33de777fac7cec70@mail.gmail.com>
Yann Simon wrote:
> 2009/11/16 Ian Hobson <ian@ianhobson.co.uk>:
>
>> My thoughts are to have 4 branches, one for each customer. 99% of all
>> changes will be needed by all (or at least most)
>> of the customers (P,W,S and E). How can I make a change to master and then
>> use git to apply those changes to the four branches, without losing the
>> differences between branches?
>>
>> For example (if this is the best way) go from this
>> O-----O-----A-----B-----C (master)
>> \----P
>> \---W
>> \--S
>> \-E
>>
>> to first this, where D is the net effect of A B and C (this is for ease of
>> reading logs, and commit messages),
>> O-----O-----D (head) \----P
>> \---W
>> \--S
>> \-E
>>
>> and then to this, (without editing all the files four times?)
>> O-----O-----D (head)
>> \----P-----D'
>> \---W----D''
>> \--S-----D'''
>> \-E-----D''''
>>
>
> What I would do is:
> - one branch for the common
> - one branch for each customer, which contains the specific
> differences compare to the common branch
>
> You could program on the common branch.
> When you are ready, you can checkout each specific branch and rebase
> on the common branch.
> For example:
> $ git checkout common
> edit, test, commit
> $ git checkout client1
> $ git rebase common
> $ git checkout client2
> $ git rebase common
>
>
Hi Yann,
I'll use master for common, unless I have a large chunk of development
to do, and see how it goes.
Many thanks.
Ian
^ permalink raw reply
* Re: [PATCH] Expand ~ and ~user in core.excludesfile, commit.template
From: Junio C Hamano @ 2009-11-16 22:49 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git, Karl Chen
In-Reply-To: <1258366060-27966-1-git-send-email-Matthieu.Moy@imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> My version is made a bit simpler by using strbuf for string
> manipulation in expand_user_path.
Nice to see people keeping track of issues that we tried to address but
didn't complete.
> I'm not sure I fully adressed Junio's point here:
We'll see ;-)
> I'm just copying back into the static buffer to let enter_repo() do
> the same string manipulation as it used to do (concatenate with .git
> suffixes). I think the whole enter_repo could use strbuf instead of
> static buffers, but that's a different point (probably made easier by
> my patch).
> diff --git a/config.c b/config.c
> index c644061..0fcc4ce 100644
> --- a/config.c
> +++ b/config.c
> @@ -351,6 +351,15 @@ int git_config_string(const char **dest, const char *var, const char *value)
> return 0;
> }
>
> +int git_config_pathname(const char **dest, const char *var, const char *value) {
> + if (!value)
> + return config_error_nonbool(var);
> + *dest = expand_user_path(value);
> + if (!*dest)
> + die("Failed to expand user dir in: '%s'", value);
> + return 0;
> +}
> +
> @@ -207,43 +208,49 @@ int validate_headref(const char *path)
> return -1;
> }
>
> -static char *user_path(char *buf, char *path, int sz)
> +static inline struct passwd *getpw_str(const char *username, size_t len)
> {
> + if (len == 0)
> + return getpwuid(getuid());
> +
> struct passwd *pw;
Decl-after-statement.
Do you need this special case of passing a zero-length string (not NULL
pointer as a string) to getpw_str() to grab the current user? Which
codepath is this needed?
> + char *username_z = xmalloc(len + 1);
> + memcpy(username_z, username, len);
> + username_z[len] = '\0';
> + pw = getpwnam(username_z);
> + free(username_z);
> + return pw;
> +}
> +/*
> + * Return a string with ~ and ~user expanded via getpw*. If buf != NULL, then
> + * it is a newly allocated string. Returns NULL on getpw failure or if
> + * path is NULL.
> + */
> +char *expand_user_path(const char *path)
> +{
> + struct strbuf user_path = STRBUF_INIT;
> + char * first_slash = strchrnul(path, '/');
> + char * to_copy;
Style: "char *first_slash"
Should't "to_copy" be initialized to "path" here? What do you copy when
path[0] is '/'?
> + if (path == NULL)
> + goto return_null;
> +
> + if (path[0] == '~') {
> + const char *username = path + 1;
> + size_t username_len = first_slash - username;
> + struct passwd *pw = getpw_str(username, username_len);
> + if (!pw)
> + goto return_null;
> + strbuf_add(&user_path, pw->pw_dir, strlen(pw->pw_dir));
> + to_copy = first_slash;
> + } else if (path[0] != '/') {
> + to_copy = path;
> }
> - return buf;
> + strbuf_add(&user_path, to_copy, strlen(to_copy));
> + return strbuf_detach(&user_path, NULL);
> +return_null:
> + strbuf_release(&user_path);
> + return NULL;
> }
> /*
> @@ -291,8 +298,17 @@ char *enter_repo(char *path, int strict)
> if (PATH_MAX <= len)
> return NULL;
> if (path[0] == '~') {
> - if (!user_path(used_path, path, PATH_MAX))
> + char *newpath = expand_user_path(path);
> + if (!newpath || (PATH_MAX - 10 < strlen(newpath))) {
> + if (path != newpath)
> + free(newpath);
Your expand_user_path() never returns the original, no?
> return NULL;
> + }
> + /* Copy back into the static buffer. A pity
> + since newpath was not bounded, but other
> + branches of the if are limited by PATH_MAX
> + anyway. */
> + strcpy(used_path, newpath); free(newpath);
> strcpy(validated_path, path);
> path = used_path;
> }
Heh, in a sense you _did_ address my point by punting, but that is Ok. As
you said earlier that would be a good topic of a separate patch.
/*
* By the way, we write our
* multi-line comments like
* this.
*/
^ permalink raw reply
* Re: [PATCH v2 0/2] user-manual: new "getting started" section
From: Felipe Contreras @ 2009-11-16 22:52 UTC (permalink / raw)
To: Nanako Shiraishi
Cc: Michael J Gruber, Jonathan Nieder, Junio C Hamano, git,
J. Bruce Fields, Hannu Koivisto, Jeff King, Wincent Colaiuta,
Matthias Lederhofer
In-Reply-To: <20091114060600.6117@nanako3.lavabit.com>
On Fri, Nov 13, 2009 at 11:06 PM, Nanako Shiraishi <nanako3@lavabit.com> wrote:
> Quoting Michael J Gruber <git@drmicha.warpmail.net>
>> If you care to go back to that discussion you see that there is good
>> reason for having both --cached and --index. They are different. "git
>> help cli" explains this nicely.
>
> The need to support both options in the same command (eg. apply) means
> that anybody who says "I don't like 'index' nor 'cache'; why don't we
> change them all to 'stage'" doesn't understand the issue.
>
> But that doesn't mean "apply --cached" vs "apply --index" is the best
> way to let the users specify which operation is requested. I don't
> think Felipe seriously wants to change them to --gogo vs --dance, but
> if he made a more constructive proposal, instead of making such a
> comment whose intended effect is only to annoy people, we may see
> an improved UI at the end. Proposing "--index-only" vs "--index-too"
> or even "--stage-only" vs "--stage-too" would have helped him appear
> to be more serious and constructive and I think your expression
> "mismatching participants" was a great way to say this.
Right, your explanation is more clear: the fact that we need both
doesn't mean we cannot use the term "stage". As to "constructive
proposal" I deliberately tried to avoid them in case somebody tried to
disregard it as bike-shedding, and move on. What I'm trying to do is
bring up the issue that the stage is not user friendly.
> There was a similar discussion about "diff --cached". The command
> compares two things and the current syntax relies on counting the
> number of treeish on the command line to specify what these two things
> are, and sometimes people are confused which way the comparison occurs.
>
> * If you have two treeish, it compares the two treeish. Specifically,
> it shows the change to make one treeish into the other treeish.
>
> * If you have one treeish, it compares the treeish with working tree
> or the index (it shows the change to make the treeish into working
> tree or the index). You need --cached to choose the "index", and
> this can safely be aliased to --staged.
>
> * If you have zero treeish, it compares the index with working tree
> (it shows the change to make the index into working tree).
>
> But it is also possible to have an alternate syntax to explicitly say
> what you are comparing with what. Perhaps these may make it unnecessary
> to remember which way the comparison occurs:
>
> git diff --tree-vs-staged HEAD
> same as "git diff --cached HEAD"
> git diff --staged-vs-tree HEAD
> same as "git diff -R --cached HEAD"
>
> git diff --staged-vs-working
> same as "git diff"
> git diff --working-vs-staged
> same as "git diff -R"
>
> git diff --tree-vs-working HEAD
> same as "git diff HEAD"
> git diff --working-vs-tree HEAD
> same as "git diff -R HEAD"
I like David Kågedal's suggestion more:
http://kerneltrap.org/mailarchive/git/2008/10/29/3857134
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH 3/3] rebase: refuse to rebase with -s ours
From: A Large Angry SCM @ 2009-11-16 23:04 UTC (permalink / raw)
To: git
Cc: Johannes Schindelin, Junio C Hamano, Thomas Rast,
Nicolas Sebrecht, Baz, Peter Krefting, Björn Steinbrink
In-Reply-To: <alpine.DEB.1.00.0911162213590.4985@pacific.mpi-cbg.de>
Johannes Schindelin wrote:
[...]
> As gitzilla once said "I cannot provide alternative patches, so that's
> that".
I'm not sure I actually said that [*1*] but I did point out that when
there is an active discussion about which of multiple ways a feature can
be implemented, the party that produces code usually gets their way.
[*1*] There was beer involved and I was jet-lagged so maybe I did say
that when I meant what I wrote above.
^ permalink raw reply
* Re: git gc - out of memory
From: Alejandro Riveira @ 2009-11-16 23:10 UTC (permalink / raw)
To: git
In-Reply-To: <df1390cc0911151033h2825053fxafe5bb2bb788fbb2@mail.gmail.com>
El Sun, 15 Nov 2009 19:33:27 +0100, Simon Strandgaard escribió:
>>
>> run « git repack -adf --window=memory » on the repo where memory is
>> escaled apropiately for your machine ?
>
> Thank you Alejandro, it now works!
ell glad it does becouse i mad a typo ...
>
> I think the default is 10, so I tried with window=5 and it completed a
> full repack.
I was trying to make you use --window-memory=[memory] not --window= ;P
>
>
> Now that it works..
> Should I report the original issue as a bug somewhere? e.g. malloc
> failed sounds like a bug.
This is the right place. Just wait for someone more knowledgeable than
me ...
>
>
>
> Kind regards
> Simon Strandgaard - http://gdtoolbox.com/
^ permalink raw reply
* Re: [PATCH] Document git-svn's first-parent rule
From: Eric Wong @ 2009-11-16 23:14 UTC (permalink / raw)
To: Junio C Hamano, Thomas Rast; +Cc: git
In-Reply-To: <ea845c8757a629d692bb6cd3827887f0e811c044.1258366486.git.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> wrote:
> git-svn has the following rule to detect the SVN base for its
> operations: find the first git-svn-id line reachable through
> first-parent ancestry. IOW,
>
> git log --grep=^git-svn-id: --first-parent -1
>
> Document this, as it is very important when using merges with git-svn.
>
> Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Thanks Thomas,
Acked-by: Eric Wong <normalperson@yhbt.net>
> ---
> Documentation/git-svn.txt | 10 ++++++++++
> 1 files changed, 10 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
> index 1812890..6da4151 100644
> --- a/Documentation/git-svn.txt
> +++ b/Documentation/git-svn.txt
> @@ -735,6 +735,16 @@ merges you've made. Furthermore, if you merge or pull from a git branch
> that is a mirror of an SVN branch, 'dcommit' may commit to the wrong
> branch.
>
> +If you do merge, note the following rule: 'git svn dcommit' will
> +attempt to commit on top of the SVN commit named in
> +------------------------------------------------------------------------
> +git log --grep=^git-svn-id: --first-parent -1
> +------------------------------------------------------------------------
> +You 'must' therefore ensure that the most recent commit of the branch
> +you want to dcommit to is the 'first' parent of the merge. Chaos will
> +ensue otherwise, especially if the first parent is an older commit on
> +the same SVN branch.
> +
> 'git clone' does not clone branches under the refs/remotes/ hierarchy or
> any 'git svn' metadata, or config. So repositories created and managed with
> using 'git svn' should use 'rsync' for cloning, if cloning is to be done
> --
^ permalink raw reply
* Re: [PATCH] RFC Allow case insensitive search flag with git-grep for fixed-strings
From: Junio C Hamano @ 2009-11-16 23:36 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git, Brian Collins, Jeff King
In-Reply-To: <20091116195050.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Quoting Brian Collins <bricollins@gmail.com>
>
>> You will have to excuse me, this is my first patch and I don't know if
>> this is the right place to post this. Apologies in advance if I'm in
>> the wrong place.
>>
>> git-grep currently throws an error when you combine the -F and -i
>> flags. This isn't in line with how GNU grep handles it. This patch
>> allows the simultaneous use of those flags.
>
> Junio, may I ask what happened to this patch?
We got sidetracked into a larger picture issues of how to allow platform
ports to selectively call out to external grep depending on the feature
set supported by the external grep implementations.
Later I looked at the original patch, the patch text looked fine (except
that I would have called the field "ignorecase", not "caseless"), but it
wasn't signed off and did not have usable log message.
And then I forgot ;-)
Thanks for a reminder, and thanks Jeff for a resend.
^ permalink raw reply
* Re: [PATCH] Expand ~ and ~user in core.excludesfile, commit.template
From: Jakub Narebski @ 2009-11-16 23:47 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git, Karl Chen
In-Reply-To: <1258366060-27966-1-git-send-email-Matthieu.Moy@imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> These config variables are parsed to substitute ~ and ~user with getpw
> entries.
>
> user_path() refactored into new function expand_user_path(), to allow
> dynamically allocating the return buffer.
>
> Original patch by Karl Chen, modified by Matthieu Moy.
>
> Signed-off-by: Karl Chen <quarl@quarl.org>
> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
> ---
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index d1e2120..c37b51d 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -380,7 +380,8 @@ Common unit suffixes of 'k', 'm', or 'g' are supported.
> core.excludesfile::
> In addition to '.gitignore' (per-directory) and
> '.git/info/exclude', git looks into this file for patterns
> - of files which are not meant to be tracked. See
> + of files which are not meant to be tracked. "~" and "~user"
> + are expanded to the user's home directory. See
> linkgit:gitignore[5].
>
> core.editor::
It would be nice to have an option to git-config which would do such
expansion, as a separate type similar to --int and --bool, e.g.:
git config --path section.key
so that not only core.excludesfile could use this new feature, but for
example also core.worktree, commit.template, gitcvs.logfile,
mailmap.file, and perhaps also *.receivepack and *.uploadpack
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Define $PERL_PATH in test-lib.sh
From: Philippe Bruhat (BooK) @ 2009-11-16 23:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7v639cqhh6.fsf@alter.siamese.dyndns.org>
On Sun, Nov 15, 2009 at 01:12:37AM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > On Tue, Nov 10, 2009 at 11:46:51AM +0100, Philippe Bruhat (BooK) wrote:
> > (snip)
> > Will this work if I just have PERL_PATH in my config.mak in the root
> > directory? Should we be adding PERL_PATH to the generated
> > GIT-BUILD-OPTIONS file in the root, which gets sourced by test-lib?
> >
> > Something like the following (completely untested) patch?
>
> Philippe, could you please help getting this topic unstuck with a "it
> works" or "it doesn't and here is a better solution"?
>
I took Jeff's patch the main Makefile, removed my patch to test-lib.sh,
and it worked. That is to say, the test suite failed on the perl tests
when the first perl in the PATH was my local perl without Error.pm
installed. With the changes, the test suite passed, even with my local
perl first in the PATH.
Patch with a reworked commit message follows.
--
Philippe Bruhat (BooK)
The truly stupid always find a way to create disaster.
(Moral from Groo #10 (Image))
^ 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