* Re: Consensus on "Git"
From: Junio C Hamano @ 2009-11-11 9:36 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, David Symonds, git
In-Reply-To: <20091111092731.GA17422@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Except for the title of every set of release notes, which all start
> with:
>
> GIT vX.Y.Z Release Notes
>
> ? :)
Yeah these were copied from release to release and I do not pay much
attention to the minute details of how my tools I wrote long time ago
spells things ;-)
Perhaps I should update my scripts to generate them.
^ permalink raw reply
* Re: Consensus on "Git"
From: Jeff King @ 2009-11-11 9:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: David Symonds, git
In-Reply-To: <20091111092731.GA17422@sigill.intra.peff.net>
On Wed, Nov 11, 2009 at 04:27:31AM -0500, Jeff King wrote:
> For a fun (ab)use of blame, you can see who wrote each of David's
> suspect lines with:
>
> git grep -n "\bGIT\b" |
> while IFS=: read file line junk; do
> git blame -f -L $line,$line $file
> done |
> less
>
> Many of them are variables (e.g., \b gets rid of "_", but we still have
> "-", so GIT-VERSION and such are still there). Many others are the title
> of the "GIT" section of the manpages. But there are some legitimate
> uses, too. Many of them blame to quite a long time ago, though (e.g.,
> Documentation/everyday.txt has two uses by you in 2005).
BTW, here is a much better grep (still a few false positives, but most
lines are meanginful):
git grep -n -E "(^|[^A-Z_-])GIT($|[^A-Z_-])" |
grep -v ':GIT$' |
while IFS=: read file line junk; do
git blame -f -L $line,$line $file
done |
less
You can really see that most of the uses of GIT are ancient. I wonder if
we should downcase the few that are in user-visible error messages. I
will let somebody else spend their time on such a conversion if they
want, though. I've already spent enough on this. :)
-Peff
^ permalink raw reply
* Re: P4 Sync problem
From: Dmitry Smirnov @ 2009-11-11 9:43 UTC (permalink / raw)
To: git
In-Reply-To: <1a6be5fa0911110043i63b5c032s7924f9f1cdfe32ee@mail.gmail.com>
Tor Arvid Lund <torarvid <at> gmail.com> writes:
> Hi. So - I think the problem is that git-p4 doesn't understand what it
> is you want to sync.
I believe it will never understand that until self.depotPaths
will be initialized.
It looks like it is intitilized from argument list only (or from already saved
settings). See P4Sync.run().
But self.getClientSpec() which is called some time before, does not init neither
self.depotPaths nor args.
I had fixed this with the following code (new lines marked with +):
if self.useClientSpec or gitConfig("git-p4.useclientspec") == "true":
+ if self.verbose:
+ print "Get client spec"
self.getClientSpec()
+ if self.verbose:
+ print "Client Spec Dirs: %s" % self.clientSpecDirs
+ if len(args) == 0:
+ for item in self.clientSpecDirs:
+ k,v = item
+ args.append(k)
Unfortunately, this fails on another stage:
>git p4 sync --verbose
Reading pipe: git config git-p4.useclientspec
Get client spec
Reading pipe: git config git-p4.user
Reading pipe: git config git-p4.password
Reading pipe: git config git-p4.port
Reading pipe: git config git-p4.host
Reading pipe: git config git-p4.client
p4 -c MYCLIENT-G client -o
Opening pipe: p4 -c MYCLIENT-G client -o
Client Spec Dirs:[ <my paths here> ]
Doing initial import of <my paths here> from revision #head into
refs/remotes/p4/master
p4 -c MYCLIENT-G files <my paths here appended with ...#head >
Opening pipe: p4 -c MYCLIENT-G files <my paths here appended with ...#head >
p4 returned an error: //MYCLIENT/path/file.c/...#head> - file(s) not in client
view.
My client spec contains some line to the file:
-//depot/path/... //MYCLIENT/null/...
//depot/path/file.cs //MYCLIENT/path/file.cs
This means that I wish to sync only file.cs into my client and get rid of other
files in this directory.
BTW, note that file extension is truncated in the log
Dmitry
^ permalink raw reply
* Re: [PATCH 2/2] pack documentation review updates
From: Scott Chacon @ 2009-11-11 10:05 UTC (permalink / raw)
To: Nanako Shiraishi
Cc: Junio C Hamano, Sverre Rabbelier, Shawn O. Pearce, git list
In-Reply-To: <20091111171924.6117@nanako3.lavabit.com>
Hey,
On Wed, Nov 11, 2009 at 9:19 AM, Nanako Shiraishi <nanako3@lavabit.com> wrote:
> Update Scott's protocol document according to review comments given by Junio.
>
> * name of "%00" byte is NUL not null;
> * requestee sends current values of its refs, not "known values";
> * consistently use "obj-id";
> * requestor chooses the capabilities it wants to be in effect;
> * pack data is sent after negotiation finishes, not just after "some of
> it is done";
> * what it has is called "its", not "it's";
> * consistently use "flush-pkt";
> * remove redundant "something like";
> * status report for send-pack is sent from the receiver, not from client;
> * don't unnecessarily say "SHOULD NOT" when existing servers can satisify
> "MUST NOT";
> * only one thin pack is sent and thickened;
> * an all-zero value is defined as a zero-id, so use it.
>
> Signed-off-by: しらいし ななこ <nanako3@lavabit.com>
> ---
I was _just_ working on this yesterday and had gotten about halfway
through - I'm traveling a lot right now, so I'm a bit behind. This
looks good, thanks for taking the time Nanako.
Signed-off-by: Scott Chacon <schacon@gmail.com>
^ permalink raw reply
* Re: Git drawbacks?
From: Dmitry Smirnov @ 2009-11-11 10:21 UTC (permalink / raw)
To: git
In-Reply-To: <loom.20091106T160709-387@post.gmane.org>
Dmitry Smirnov <divis1969 <at> gmail.com> writes:
Ok, I have heard a lot of perfect words about Git. I'm almost on your side :-)
Just need some advice on (small for Git, I hope) problem.
I'm trying to import P4 depot into Git (for mirroring purpose).
It seems a non-trivial task with the current git-p4 script.
Perhaps, I had selected a wrong way: i'm trying to import some client.
In fact, as I said in previous mails, typically I have few similar clients.
So, maybe it is simpler to import some set of branches (which I suppose a little
bit simpler with git-p4).
Unfortunaley, the directory structure of the depot differs from client's (i.e.
working tree differs from repository tree).
For example,
//depot/component/version could be mapped to the
<root_of_working_tree>/component.
Thus if I import //depot/component/version1 and //depot/component/version2
as is, I should be able to checkout either version1 or version2.
Note that there could be few components in the same working tree:
//depot/component1/version1 (mapped to <root>/component1)
//depot/component2/versionX (mapped to <root>/component2)
//depot/component3/versionY (mapped to <root>/component3)
With Perforce, there could also be a more complex mappings, but maybe we will
discuss it later).
Is there any way to make this mapping with Git? Should I invent some kind of
tool like 'repo' or there is a simpler way?
Dmitry
^ permalink raw reply
* Re: [PATCH v5 1/2] filter-branch: stop special-casing $filter_subdir argument
From: Thomas Rast @ 2009-11-11 10:24 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Junio C Hamano
In-Reply-To: <4AFA7B9A.4090005@viscovery.net>
Johannes Sixt wrote in the other reply:
> I thought that the intention to give an extra path argument is to reduce
> the number of commits that remain in the rewritten history. But by giving
> --subdirectory-filter, the path filter actually loosened, and many more
> commits are rewritten.
Right, I had a thinko there, the path filter adds up as an "or", so
filtering for paths outside the subdir loosens it (and filtering for
more paths inside doesn't make a difference).
> Since your intention to write this patch is actually to implement
> --remap-to-ancestor, I suggest that we defer the question whether the
> above use-case makes sense, and only rewrite this particular paragraph in
> the commit message to point out the real bug:
Agreed.
Johannes Sixt wrote:
> Furthermore, --subdirectory-filter supplies its own '--', and if the user
> provided one himself, such as in
>
> git filter-branch --subdirectory-filter subdir -- --all -- subdir/file
>
> an extra '--' was used as path filter in the call to git-rev-list that
> determines the commits that shall be rewritten.
There's some stray space here that should probably also be removed.
> Here it is. The interdiff to your version is merely
[...]
> # we need "--" only if there are no path arguments in $@
> nonrevs=$(git rev-parse --no-revs "$@") || exit
> -dashdash=${nonrevs+"--"}
> +test -z "$nonrevs" && dashdash=-- || dashdash=
Ack.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: git-svn problem with v1.6.5
From: Pascal Obry @ 2009-11-11 10:28 UTC (permalink / raw)
To: Avery Pennarun, Eric Wong, adambrewster; +Cc: git list
In-Reply-To: <32541b130911101428t50038cfcsf37e3ea9edb26f64@mail.gmail.com>
Avery,
> Is d2cf08bb67e4b7da33a250127aab784f1f2f58d3 a valid revision? (git
> log d2cf08bb67e4b7da33a250127aab784f1f2f58d3).
No.
> Is refs/remotes/svn/trunk valid? (git log refs/remotes/svn/trunk).
Yes.
> It seems like a strange problem.
Agreed!
> You could try using git bisect to figure out which exact commit to
> git.git created the problem.
I wanted to avoid that :) Anyway, here is the culprit:
commit 6f5748e14cc5bb0a836b649fb8e2d6a5eb166f1d
Author: Adam Brewster <adambrewster@gmail.com>
Date: Tue Aug 11 23:14:27 2009 -0400
svn: allow branches outside of refs/remotes
It may be convenient for some users to store svn remote tracking
branches outside of the refs/remotes/ heirarchy.
To accomplish this feat, this patch includes the entire path to
the ref in $r->{'refname'} in &read_all_remotes and tries to change
references to this entry so the new value makes sense.
[ew: fixed backwards compatibility, long lines]
Signed-off-by: Adam Brewster <adambrewster@gmail.com>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
git-svn.perl | 83
++++++++++++++++++++++----------------
t/lib-git-svn.sh | 2 +-
t/t9104-git-svn-follow-parent.sh | 10 ++--
t/t9107-git-svn-migrate.sh | 14 +++----
t/t9143-git-svn-gc.sh | 10 ++--
t/t9144-git-svn-old-rev_map.sh | 31 ++++++++++++++
6 files changed, 96 insertions(+), 54 deletions(-)
But frankly I'm no expert on Perl... I fear that I won't be able to
debug that!
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net - http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B
^ permalink raw reply
* Re: [ANNOUNCE] Girocco hosting infrastructure v1.0
From: Michael J Gruber @ 2009-11-11 11:03 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20091110104027.GI17748@machine.or.cz>
Petr Baudis venit, vidit, dixit 10.11.2009 11:40:
> Hello!
>
> I would like to announce Girocco-1.0, the first stable release of
> a universal Git project hosting infrastructure. You can get it at
...
> If you are used to repo.or.cz, what's new in Girocco at the user's
> end?
>
> * Friendlier homepage.
>
> * Friendlier project/user management interface.
>
> * Friendlier mirror cloning process (you can see the progress in your
> browser).
>
> * Support for automatic Git mirroring of SVN repositories.
Hi there,
thanks for everything. I'm glad things aren't "too friendly": I never
know how to navigate the "shinier" hosting alternatives...
How does the svn mirroring work? Do I simply enter a svn:// url for
"Anywhere"? Is it always standard layout (git svn clone -s)?
Can I specify an authors file?
Michael
^ permalink raw reply
* tracking binaries - help needed
From: Dilip M @ 2009-11-11 11:00 UTC (permalink / raw)
To: git
In-Reply-To: <c94f8e120911102245gd7cce07mdb87fdb870880530@mail.gmail.com>
Hello,
I know, tracking bin are not good, but there will be still some docs which has
to be versioned.
I am using, msysgit.git version 1.6.5.1.1367.gcd48.
I just did a add of some MS EXCEL file and When even I open and close these
files, git status shows these files as 'modified'
How can I deal with these files?
I believe its the same case if I have repo on UNIX too.
--
Dilip
^ permalink raw reply
* Re: [ANNOUNCE] Girocco hosting infrastructure v1.0
From: Petr Baudis @ 2009-11-11 11:30 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <4AFA9A1E.5050107@drmicha.warpmail.net>
On Wed, Nov 11, 2009 at 12:03:58PM +0100, Michael J Gruber wrote:
> How does the svn mirroring work? Do I simply enter a svn:// url for
> "Anywhere"? Is it always standard layout (git svn clone -s)?
> Can I specify an authors file?
Yes, you simply enter a svn:// URL (http:// URLs are currently not
supported), it is always standard layout, no you can't specify an
authors file.
The support is only very basic, if you want anything better, please
send me a patch. :-)
--
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: P4 Sync problem
From: Tor Arvid Lund @ 2009-11-11 12:00 UTC (permalink / raw)
To: Dmitry Smirnov; +Cc: git
In-Reply-To: <loom.20091111T100646-406@post.gmane.org>
On Wed, Nov 11, 2009 at 10:43 AM, Dmitry Smirnov <divis1969@gmail.com> wrote:
> Tor Arvid Lund <torarvid <at> gmail.com> writes:
>
>> Hi. So - I think the problem is that git-p4 doesn't understand what it
>> is you want to sync.
>
> I believe it will never understand that until self.depotPaths
> will be initialized.
Correct.
> It looks like it is intitilized from argument list only (or from already saved
> settings). See P4Sync.run().
Also correct, me thinks.
> But self.getClientSpec() which is called some time before, does not init neither
> self.depotPaths nor args.
Correct again. The useclientspec flag was created (by me) as a simple
way to filter out files that I did not want to download (the reason
being my company tends to mix binaries with source files causing
unnecessary long sync times). So it was never used to tell git-p4
_what_ to sync, but rather what to _not_ sync.
So - in your case, you could have tried to just say "git p4 sync
//depot@all", and if your clientspec contained, say, only
"//depot/path/projectX", then projectX should be the only thing that
got downloaded. Keep in mind, though, that git-p4 would still ask the
p4 server for _all_ of its changelists, loop through them, and check
each file in each changelist against the clientSpecDirs array...
> I had fixed this with the following code (new lines marked with +):
> if self.useClientSpec or gitConfig("git-p4.useclientspec") == "true":
> + if self.verbose:
> + print "Get client spec"
> self.getClientSpec()
> + if self.verbose:
> + print "Client Spec Dirs: %s" % self.clientSpecDirs
> + if len(args) == 0:
> + for item in self.clientSpecDirs:
> + k,v = item
> + args.append(k)
Well, I see what you're trying to do, but I would not want to see that
patch in the official script, because some (most?) people (myself, at
least) use git-p4 to clone single projects out of a perforce depot
that may contain many projects. I do this myself by doing:
git p4 clone //depot/path/to/projectX@all
I usually use one clientspec in perforce, and I do not want to change
that... With your patch, I would be in trouble since my clientspec
contains "//depot/..." (followed by a lot of lines starting with '-')
> Unfortunately, this fails on another stage:
>
>>git p4 sync --verbose
<snip>
> Opening pipe: p4 -c MYCLIENT-G files <my paths here appended with ...#head >
> p4 returned an error: //MYCLIENT/path/file.c/...#head> - file(s) not in client
> view.
>
> My client spec contains some line to the file:
> -//depot/path/... //MYCLIENT/null/...
> //depot/path/file.cs //MYCLIENT/path/file.cs
>
> This means that I wish to sync only file.cs into my client and get rid of other
> files in this directory.
> BTW, note that file extension is truncated in the log
Yep - this is a bug (or lack of a feature, if you will...). The
clientspec functionality in git-p4 supports directories only. If you
look at the getClientSpec function, you see that it looks for "...".
It's probably an easy fix if you want to support having single files
in the client spec. I didn't (and don't) need it, so it didn't occur
to me at the time...
If you want to fix it, you might want to rename clientSpecDirs to
clientSpecEntries or something like that.
Btw... Am I understanding correctly what it is you wish to accomplish?
I'm guessing that you have a perforce server with a client spec set
up, and you want to sync everything on the entire server according to
that client spec?
-Tor Arvid-
^ permalink raw reply
* Locally manage user/branch setting files without pushing them remotely
From: Daniele Segato @ 2009-11-11 12:01 UTC (permalink / raw)
To: Git Mailing List
Hi,
I had a situation I don't know how to manage with Git.
The project has a lot of setting that are really binded to the user
and should not go pushed in a remote repository (example: database
connections parameters / filesystem paths)
We have a .template file for those settings but the actual settings
are really binded to the user environment.
I added those files to the .gitignore but now I can't keep an history
of them and I can't use different version of them in different
branches.
I tell you what's the real situation but I will simplify things a
little, suppose I only have two branches: master and experiments.
I've a java application and some ANT script to automatizations like
compiling, packaging and deploying stuffs.
On my system I had two application servers and two databases one for
"master" and the other for "experiment".
There is a property files with the path of the two application servers
and the parameters to connect at the DB.
The ant script automatically deploy on the right application server
and automatically set the properties to connect at the right database.
This allow me to clean my experimantal database everytimes I need to
and start over by a clean situation and keep the "master" one
populated with all the data so I can do stress test/update procedures
test and so on...
At the moment I manually modify that property files when I checkout
one of the two branches and I need to deploy it to test or whatever.
Is there a way with Git to automatically switch that file when i
switch through branches?
It would be really perfect if I could also keep version of that file
so that when I checkout an old commit I had the options I was using
when I was testing that commit.
Ideally that means that should be some files that are kept within each
commit but they are not pushed to a remote repository.
(Even if i'm talking about pushing I'm using git-svn because my
company still use SVN as versioning system so I don't push but i do
git svn dcommit when committing on a remote repository)
How do you manage situation like this?
thanks,
Daniele
^ permalink raw reply
* Re: [PATCH v5 1/2] filter-branch: stop special-casing $filter_subdir argument
From: Johannes Sixt @ 2009-11-11 12:10 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Junio C Hamano
In-Reply-To: <200911111124.52340.trast@student.ethz.ch>
Thomas Rast schrieb:
> Johannes Sixt wrote:
>> Furthermore, --subdirectory-filter supplies its own '--', and if the user
>> provided one himself, such as in
>>
>> git filter-branch --subdirectory-filter subdir -- --all -- subdir/file
>>
>> an extra '--' was used as path filter in the call to git-rev-list that
>> determines the commits that shall be rewritten.
>
> There's some stray space here that should probably also be removed.
Oh, right. Junio, you can pick up the 2-patch series from
git://repo.or.cz/git/mingw/j6t.git filter-branch
-- Hannes
^ permalink raw reply
* Re: Locally manage user/branch setting files without pushing them remotely
From: Yann Simon @ 2009-11-11 12:14 UTC (permalink / raw)
To: Daniele Segato; +Cc: Git Mailing List
In-Reply-To: <9accb4400911110401g5c44d011u50cafcfe736a2ec6@mail.gmail.com>
2009/11/11 Daniele Segato <daniele.bilug@gmail.com>:
> I had a situation I don't know how to manage with Git.
>
> The project has a lot of setting that are really binded to the user
> and should not go pushed in a remote repository (example: database
> connections parameters / filesystem paths)
> We have a .template file for those settings but the actual settings
> are really binded to the user environment.
> I added those files to the .gitignore but now I can't keep an history
> of them and I can't use different version of them in different
> branches.
>
> I tell you what's the real situation but I will simplify things a
> little, suppose I only have two branches: master and experiments.
>
> I've a java application and some ANT script to automatizations like
> compiling, packaging and deploying stuffs.
>
> On my system I had two application servers and two databases one for
> "master" and the other for "experiment".
> There is a property files with the path of the two application servers
> and the parameters to connect at the DB.
>
> The ant script automatically deploy on the right application server
> and automatically set the properties to connect at the right database.
>
> This allow me to clean my experimantal database everytimes I need to
> and start over by a clean situation and keep the "master" one
> populated with all the data so I can do stress test/update procedures
> test and so on...
>
> At the moment I manually modify that property files when I checkout
> one of the two branches and I need to deploy it to test or whatever.
>
>
>
> Is there a way with Git to automatically switch that file when i
> switch through branches?
> It would be really perfect if I could also keep version of that file
> so that when I checkout an old commit I had the options I was using
> when I was testing that commit.
>
> Ideally that means that should be some files that are kept within each
> commit but they are not pushed to a remote repository.
> (Even if i'm talking about pushing I'm using git-svn because my
> company still use SVN as versioning system so I don't push but i do
> git svn dcommit when committing on a remote repository)
>
> How do you manage situation like this?
I am in the same situation.
What I did is not to add these files to .gitignore.
On my "work" branch, I commited these files in a separate commit
"local changes".
When I want to push to svn, I switch to the branch "master", and
cherry-pick the commit I want to push.
$ git checkout master
$ git svn rebase
$ git cherry-pick work
$ git svn dcommit
$ git checkout work
$ git rebase master
This workflow could maybe be better. Suggestions welcome.
Yann
^ permalink raw reply
* Re: P4 Sync problem
From: Dmitry Smirnov @ 2009-11-11 12:39 UTC (permalink / raw)
To: git
In-Reply-To: <1a6be5fa0911110400l1fe931afmbb53ceba8704e029@mail.gmail.com>
Tor Arvid Lund <torarvid <at> gmail.com> writes:
> Well, I see what you're trying to do, but I would not want to see that
> patch in the official script, because some (most?) people (myself, at
> least) use git-p4 to clone single projects out of a perforce depot
> that may contain many projects. I do this myself by doing:
>
> git p4 clone //depot/path/to/projectX <at> all
>
> I usually use one clientspec in perforce, and I do not want to change
> that... With your patch, I would be in trouble since my clientspec
> contains "//depot/..." (followed by a lot of lines starting with '-')
Well, does this mean that if you try to sync the client in perforce (visual or
command line), you will sync all the projects?
In that case, git p4 will require significant effort to satisfy both of us :-)
Unfortunatly, it seems I'm in minory group of git-p4 users...
i would propose to use both command-line arguments and a client spec
to create a correct filter of what should be synced/cloned.
BTW, it looks this script does not honor neither the order of paths
in the spec (which can be important) nor mapping of the files to a local tree.
> If you want to fix it, you might want to rename clientSpecDirs to
> clientSpecEntries or something like that.
For now, I just commented out two lines in the run() procedure:
#if not p.endswith("/"):
# p += "/"
> Btw... Am I understanding correctly what it is you wish to accomplish?
> I'm guessing that you have a perforce server with a client spec set
> up, and you want to sync everything on the entire server according to
> that client spec?
yes. Client spec completely defines the project layout for me.
It contains paths to some components that are mapped to the
client working tree.
Just if your CS contain
//depot/path/to/projectX/... //CLIENT/...
^ permalink raw reply
* Re: Locally manage user/branch setting files without pushing them remotely
From: Daniele Segato @ 2009-11-11 13:00 UTC (permalink / raw)
To: Yann Simon; +Cc: Git Mailing List
In-Reply-To: <551f769b0911110414j759bd4ayfedfa779307e1a63@mail.gmail.com>
On Wed, Nov 11, 2009 at 1:14 PM, Yann Simon <yann.simon.fr@gmail.com> wrote:
> I am in the same situation.
> What I did is not to add these files to .gitignore.
> On my "work" branch, I commited these files in a separate commit
> "local changes".
> When I want to push to svn, I switch to the branch "master", and
> cherry-pick the commit I want to push.
> $ git checkout master
> $ git svn rebase
> $ git cherry-pick work
> $ git svn dcommit
> $ git checkout work
> $ git rebase master
>
> This workflow could maybe be better. Suggestions welcome.
hum
but I don't want to push those files
the idea of placing those files in a separate commit could be handy...
If I create a branch for each version of the file: example
experiments-local, master-local then I could keep version of the file
there and cherry pick them when needed
like this:
$ git checkout experiment
$ # do work
$ git commit -a -m "my recent work"
$ git cherry-pick experiment-local
$ # test / compile / whatever
$ git reset --hard HEAD~ # undo the cherry-pick because i don't want to push it
$ git svn dcommit / git chechout another-branch
but I could forgot to reset --hard HEAD~ and I had to be very careful...
instead I would place those files in separate stash called
"experiments", "master" and apply the right stash when I need and then
discard it before switching branch..
this is something I hadn't thinked about
$ git checkout experiment
$ # do work
$ git stash apply experiment-stash # don't know if i could use name to
reference stashes
# test / compile / whatever
$ rm mypropfile.properties
$ git add <files...>
$ git commit
$ git svn dcommit / git checkout another-branch
this way I still had to remove the file manually but since I never use
git commit -a I probably wouldn't add it to a commit by mistake.
This could be more handy then the way I act now...
still I hope there is a better way to handle situations like this
regards,
Daniele
^ permalink raw reply
* Re: [PATCHv2] Update gitworkflows man page to include release workflow
From: Thiago Farina @ 2009-11-11 13:05 UTC (permalink / raw)
To: rocketraman; +Cc: git
In-Reply-To: <1257869339-15999-2-git-send-email-rocketraman@fastmail.fm>
Hi,
On Tue, Nov 10, 2009 at 2:08 PM, <rocketraman@fastmail.fm> wrote:
> From: Raman Gupta <raman@rocketraman.com>
>
> The gitworkflows man page currently provides an overview of the workflows
> used by git.git itself to serve as inspiration for people to use when
> designing their own workflows. The current man page does a reasonable
> job at describing the development process, but it does not contain any
> guidance as to the workflow used for releases. Now add a basic
> introduction to the branch management required for a release, so that a
> reader may understand how the maint, master, next, and topic branches are
> affected.
Here
http://git.kernel.org/?p=git/git.git;a=blob;f=Checklist.txt;h=37745f39487537117fb7f3a9a6f5b8e7d989a884;hb=refs/heads/todo
there is a release checklist, maybe you could extend your patch to
include more information from this?
^ permalink raw reply
* Re: Locally manage user/branch setting files without pushing them remotely
From: Yann Simon @ 2009-11-11 13:06 UTC (permalink / raw)
To: Daniele Segato; +Cc: Git Mailing List
In-Reply-To: <9accb4400911110500y37437dc5h16388b07a734dc6d@mail.gmail.com>
2009/11/11 Daniele Segato <daniele.bilug@gmail.com>:
> On Wed, Nov 11, 2009 at 1:14 PM, Yann Simon <yann.simon.fr@gmail.com> wrote:
>> I am in the same situation.
>> What I did is not to add these files to .gitignore.
>> On my "work" branch, I commited these files in a separate commit
>> "local changes".
>> When I want to push to svn, I switch to the branch "master", and
>> cherry-pick the commit I want to push.
>> $ git checkout master
>> $ git svn rebase
>> $ git cherry-pick work
>> $ git svn dcommit
>> $ git checkout work
>> $ git rebase master
>>
> hum
> but I don't want to push those files
I explained myself not well.
In my "work" branch, there is
"local changes", with the local configuration files
and then "commit xyz to push"
That's why I make a git cherry-pick work to get the last commit, the
one to push.
Yann
^ permalink raw reply
* Re: Locally manage user/branch setting files without pushing them remotely
From: Paolo Ciarrocchi @ 2009-11-11 13:46 UTC (permalink / raw)
To: Daniele Segato; +Cc: Yann Simon, Git Mailing List
In-Reply-To: <9accb4400911110500y37437dc5h16388b07a734dc6d@mail.gmail.com>
On Wed, Nov 11, 2009 at 2:00 PM, Daniele Segato <daniele.bilug@gmail.com> wrote:
> On Wed, Nov 11, 2009 at 1:14 PM, Yann Simon <yann.simon.fr@gmail.com> wrote:
>> I am in the same situation.
>> What I did is not to add these files to .gitignore.
>> On my "work" branch, I commited these files in a separate commit
>> "local changes".
>> When I want to push to svn, I switch to the branch "master", and
>> cherry-pick the commit I want to push.
>> $ git checkout master
>> $ git svn rebase
>> $ git cherry-pick work
>> $ git svn dcommit
>> $ git checkout work
>> $ git rebase master
>>
>> This workflow could maybe be better. Suggestions welcome.
>
> hum
> but I don't want to push those files
If you follow Yann's advise you won't push to the svn repo the "private" files,
they will be /only/ stored in you local repo.
The cons of that approach is that you will have to cherrypick all the
commits you want to push to the svn repo from the "working branch" to
the master branch.
Ciao,
--
Paolo
^ permalink raw reply
* Move repository from OS X to Windows
From: Thomas Singer @ 2009-11-11 13:32 UTC (permalink / raw)
To: git
Hi,
I've cloned a very large repository on OS X and want to move that to Windows
(trying to avoid to clone the repository a second time). What steps should I
do to make it working (currently, I'm getting an error on pull/merge that
"Entry 'foo' is not uptodate. Cannot merge.")?
Thanks in advance,
Tom
^ permalink raw reply
* Unhelpful "branch.master.remote = <nickname>" advice?
From: Jan Nieuwenhuizen @ 2009-11-11 13:22 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 998 bytes --]
Hi,
git pull -r*) URL says:
If you often merge with the same branch, you may want to
configure the following variables in your configuration
file:
branch.master.remote = <nickname>
branch.master.merge = <remote-ref>
remote.<nickname>.url = <url>
remote.<nickname>.fetch = <refspec>
and after cut-and-pasting that into .git/config, replacing
<foo> with values, I get
$ git pull -r http://github.com/../../master
fatal: bad config file line 17 in .git/config
where line 17 is [without any indentation]
branch.master.remote = eddy
This is with git version version 1.6.3.3
Greetings,
Jan. -- who just finds out the uninstall target is missing?!?
See attached.
*) I've been wondering why GIT lacks a "update", ie
pull-without-merge command. You almost never want
to git pull /without/ -r?
--
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
Avatar®: http://AvatarAcademy.nl | http://lilypond.org
[-- Attachment #2: 0001-Makefile-add-uninstall-target.-Fixes-elementary-good.patch --]
[-- Type: text/x-patch, Size: 3234 bytes --]
>From 5b5107e2887b11cab3a391bd550d30c7df68242f Mon Sep 17 00:00:00 2001
From: Jan Nieuwenhuizen <janneke@gnu.org>
Date: Wed, 11 Nov 2009 14:19:00 +0100
Subject: [PATCH] Makefile: add uninstall target. Fixes elementary good cleaning manners.
* Modified Makefile
* Modified gitk-git/Makefile
* Modified perl/Makefile
* Modified templates/Makefile
---
Makefile | 18 +++++++++++++++++-
gitk-git/Makefile | 2 ++
perl/Makefile | 2 +-
templates/Makefile | 5 +++++
4 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index 5d5976f..135c3ac 100644
--- a/Makefile
+++ b/Makefile
@@ -1781,7 +1781,23 @@ quick-install-man:
quick-install-html:
$(MAKE) -C Documentation quick-install-html
+bindir_PROGRAMS = git$X git-upload-pack$X git-receive-pack$X git-upload-archive$X git-shell$X git-cvsserver
+uninstall:
+ifndef NO_TCLTK
+ $(MAKE) -C gitk-git uninstall
+ $(MAKE) -C git-gui gitexecdir='$(gitexec_instdir_SQ)' uninstall
+endif
+ifndef NO_PERL
+ $(MAKE) -C perl prefix='$(prefix_SQ)' DESTDIR='$(DESTDIR_SQ)' uninstall
+endif
+ $(MAKE) -C templates DESTDIR='$(DESTDIR_SQ)' uninstall
+ $(RM) $(ALL_PROGRAMS:%='$(DESTDIR_SQ)$(gitexec_instdir_SQ)'/%)
+ $(RM) $(BUILT_INS:%='$(DESTDIR_SQ)$(gitexec_instdir_SQ)'/%)
+ $(RM) $(OTHER_PROGRAMS:%='$(DESTDIR_SQ)$(gitexec_instdir_SQ)'/%)
+ -rmdir -p '$(DESTDIR_SQ)$(gitexec_instdir_SQ)'
+ $(RM) $(bindir_PROGRAMS:%='$(DESTDIR_SQ)$(bindir_SQ)'/%)
+ -rmdir -p '$(DESTDIR_SQ)$(bindir_SQ)'
### Maintainer's dist rules
@@ -1857,7 +1873,7 @@ ifndef NO_TCLTK
endif
$(RM) GIT-VERSION-FILE GIT-CFLAGS GIT-GUI-VARS GIT-BUILD-OPTIONS
-.PHONY: all install clean strip
+.PHONY: all install uninstall clean strip
.PHONY: shell_compatibility_test please_set_SHELL_PATH_to_a_more_modern_shell
.PHONY: .FORCE-GIT-VERSION-FILE TAGS tags cscope .FORCE-GIT-CFLAGS
.PHONY: .FORCE-GIT-BUILD-OPTIONS
diff --git a/gitk-git/Makefile b/gitk-git/Makefile
index e1b6045..d68f19a 100644
--- a/gitk-git/Makefile
+++ b/gitk-git/Makefile
@@ -47,6 +47,8 @@ install:: all
uninstall::
$(foreach p,$(ALL_MSGFILES), $(RM) '$(DESTDIR_SQ)$(msgsdir_SQ)'/$(notdir $p) &&) true
$(RM) '$(DESTDIR_SQ)$(bindir_SQ)'/gitk
+ -rmdir -p '$(DESTDIR_SQ)$(bindir_SQ)'/gitk
+ -rmdir -p '$(DESTDIR_SQ)$(msgsdir_SQ)'
clean::
$(RM) gitk-wish po/*.msg
diff --git a/perl/Makefile b/perl/Makefile
index 4ab21d6..25fc304 100644
--- a/perl/Makefile
+++ b/perl/Makefile
@@ -10,7 +10,7 @@ ifndef V
QUIET = @
endif
-all install instlibdir: $(makfile)
+all install instlibdir uninstall: $(makfile)
$(QUIET)$(MAKE) -f $(makfile) $@
clean:
diff --git a/templates/Makefile b/templates/Makefile
index 408f013..f4048d9 100644
--- a/templates/Makefile
+++ b/templates/Makefile
@@ -51,3 +51,8 @@ install: all
$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(template_instdir_SQ)'
(cd blt && $(TAR) cf - .) | \
(cd '$(DESTDIR_SQ)$(template_instdir_SQ)' && umask 022 && $(TAR) xof -)
+
+uninstall:
+ -(cd blt && find . -type f) | (cd '$(DESTDIR_SQ)$(template_instdir_SQ)' && xargs $(RM))
+ -(cd blt && find . -mindepth 1 -type d) | (cd '$(DESTDIR_SQ)$(template_instdir_SQ)' && xargs rmdir)
+ -rmdir -p '$(DESTDIR_SQ)$(template_instdir_SQ)'
--
1.6.3.3
^ permalink raw reply related
* Re: P4 Sync problem
From: Tor Arvid Lund @ 2009-11-11 13:54 UTC (permalink / raw)
To: Dmitry Smirnov; +Cc: git
In-Reply-To: <loom.20091111T131837-901@post.gmane.org>
On Wed, Nov 11, 2009 at 1:39 PM, Dmitry Smirnov <divis1969@gmail.com> wrote:
> Tor Arvid Lund <torarvid <at> gmail.com> writes:
>
>
>> Well, I see what you're trying to do, but I would not want to see that
>> patch in the official script, because some (most?) people (myself, at
>> least) use git-p4 to clone single projects out of a perforce depot
>> that may contain many projects. I do this myself by doing:
>>
>> git p4 clone //depot/path/to/projectX <at> all
>>
>> I usually use one clientspec in perforce, and I do not want to change
>> that... With your patch, I would be in trouble since my clientspec
>> contains "//depot/..." (followed by a lot of lines starting with '-')
>
> Well, does this mean that if you try to sync the client in perforce (visual or
> command line), you will sync all the projects?
Yes, but I generally try to not use perforce, but git instead :-)
> In that case, git p4 will require significant effort to satisfy both of us :-)
> Unfortunatly, it seems I'm in minory group of git-p4 users...
I don't know, but if I were to guess, then yes, you probably are... If
you have a complex perforce client spec setup, then there may of
course be problems that git-p4 might not solve for you. Since nobody
has volunteered to implement the features you describe yet, I believe
that most of us git-p4 users have fairly simple client spec setups.
For me, most projects in p4 are such that I can give one root
directory to "git p4 sync", and it works for me. I of course have
several git projects that sync from the same p4 server (only with
different root dirs). In cases where you have dependencies between
such projects, you should maybe read about git submodules - or maybe
googles "repo" script (search for "google repo git"). I don't know
much about any of these, other than 'they exist, and seemingly try to
solve such issues' :-/
> i would propose to use both command-line arguments and a client spec
> to create a correct filter of what should be synced/cloned.
> BTW, it looks this script does not honor neither the order of paths
> in the spec (which can be important) nor mapping of the files to a local tree.
When you have a client spec like:
//depot/A/...
-//depot/A/B/...
//depot/A/B/C/...
... git-p4 sorts these paths by length. For a given filename, it finds
the longest path that matches that files directory, and if that path
starts with a '-', the file is not synced (for a file
"//depot/A/B/myfile.c" it gets a match on "-//depot/A/B/...", and
myfile.c is not synced, but the file "//depot/A/B/C/myotherfile.c" it
matches "//depot/A/B/C/...")
Do you have an example that shows how it might fail?
And no, git-p4 does not care about the local mappings, it reads only
the server part.
-Tor Arvid-
>> If you want to fix it, you might want to rename clientSpecDirs to
>> clientSpecEntries or something like that.
>
> For now, I just commented out two lines in the run() procedure:
> #if not p.endswith("/"):
> # p += "/"
>
>> Btw... Am I understanding correctly what it is you wish to accomplish?
>> I'm guessing that you have a perforce server with a client spec set
>> up, and you want to sync everything on the entire server according to
>> that client spec?
>
> yes. Client spec completely defines the project layout for me.
> It contains paths to some components that are mapped to the
> client working tree.
> Just if your CS contain
>
> //depot/path/to/projectX/... //CLIENT/...
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: Unhelpful "branch.master.remote = <nickname>" advice?
From: Tomas Carnecky @ 2009-11-11 14:08 UTC (permalink / raw)
To: Jan Nieuwenhuizen; +Cc: git
In-Reply-To: <1257945756.26362.79.camel@heerbeest>
On Nov 11, 2009, at 2:22 PM, Jan Nieuwenhuizen wrote:
> Hi,
>
> git pull -r*) URL says:
>
> If you often merge with the same branch, you may want to
> configure the following variables in your configuration
> file:
>
> branch.master.remote = <nickname>
> branch.master.merge = <remote-ref>
> remote.<nickname>.url = <url>
> remote.<nickname>.fetch = <refspec>
These are meant to be used with git-config(1):
git config branch.master.remote <nickname>
Or if you want to manually edit the config file, add this:
[branch "master"]
remote = <nickname>
etc.
>
> and after cut-and-pasting that into .git/config, replacing
> <foo> with values, I get
>
> $ git pull -r http://github.com/../../master
> fatal: bad config file line 17 in .git/config
>
> where line 17 is [without any indentation]
>
> branch.master.remote = eddy
>
> This is with git version version 1.6.3.3
>
> Greetings,
> Jan. -- who just finds out the uninstall target is missing?!?
> See attached.
Next time please send patches inline, it's easier to review them that
way.
>
> *) I've been wondering why GIT lacks a "update", ie
> pull-without-merge command. You almost never want
> to git pull /without/ -r?
As 'pull == fetch + merge' (pull -r == fetch + rebase), pull without
merge would be fetch.
tom
^ permalink raw reply
* Re: commit log encoding [Was: [PATCH 1/2] tree-wide: fix typos "offest" -> "offset"]
From: Uwe Kleine-König @ 2009-11-11 14:13 UTC (permalink / raw)
To: Jiri Kosina; +Cc: git
In-Reply-To: <alpine.LSU.2.00.0911111318260.15039@wotan.suse.de>
On Wed, Nov 11, 2009 at 01:19:32PM +0100, Jiri Kosina wrote:
> On Wed, 11 Nov 2009, Uwe Kleine-König wrote:
>
> > > Thanks for noticing, I had a bug in my git charset config for quite some
> > > time. Fixed it now.
> > Now my name is latin1 encoded. It should be utf-8, doesn't it?
>
> It's not latin1, it's iso-8859-2
For my name it makes no difference.
> which is what I use on my terminals.
> And git can handle that fine too (it stores the encoding together with the
> commit).
Ah, OK, that's news to me, but you're right. I have here:
~/gsrc/linux-2.6$ git cat-file commit 30ff0743f88a70f52a4de5ea5bcb1fd29bcfab2d
tree 6121d35bb2606878be636e897fa77cd51804d724
parent 916b7c73db593510d5c38706be2f2888981747ee
author Uwe Kleine-K�nig <u.kleine-koenig@pengutronix.de> 1256757064 +0100
committer Jiri Kosina <jkosina@suse.cz> 1257780224 +0100
encoding ISO-8859-2
tree-wide: fix typos "couter" -> "counter"
This patch was generated by
git grep -E -i -l 'couter' | xargs -r perl -p -i -e 's/couter/counter/'
Signed-off-by: Uwe Kleine-K�nig <u.kleine-koenig@pengutronix.de>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
So the remaining question is: Does the encoding specified in the
encoding "header" also apply to the other headers?
If yes[1] then there's a bug in git-shortlog
~/gsrc/linux-2.6$ git shortlog linus/master..trivial/for-next | grep Uwe
Uwe Kleine-K�nig (5):
(with linus/master = 799dd75b1a8380a967c929a4551895788c374b31,
trivial/for-next = 4030ec040a0e21fe9953da70eaa59ee7b4f2297b).
Best regards
Uwe
[1] git log linus/master..trivial/for-next looks OK, so I suspect it
does apply.
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: Unhelpful "branch.master.remote = <nickname>" advice?
From: Jan Krüger @ 2009-11-11 14:13 UTC (permalink / raw)
To: Jan Nieuwenhuizen; +Cc: git
In-Reply-To: <1257945756.26362.79.camel@heerbeest>
Hi,
> git pull -r*) URL says: [...]
> branch.master.remote = <nickname>
> and after cut-and-pasting that into .git/config, replacing
> <foo> with values, I get [...]
> fatal: bad config file line 17 in .git/config
> where line 17 is [without any indentation]
> branch.master.remote = eddy
The confusion is that while you can set values with this syntax if
you're using git config (git config branch.master.remote <some value>),
they're written differently in actual config files:
[branch "master"]
remote = <nickname>
merge = <remote-ref>
[remote "<nickname>"]
url = <url>
fetch = <refspec>
I can't think of a message of comparable length that would make this
clearer, though.
> Jan. -- who just finds out the uninstall target is missing?!?
> See attached.
I have no comments about the patch contents themselves, but please read
Documentation/SubmittingPatches. Most importantly, patches are
usually sent inline here, and without a signoff line they can't be
accepted for inclusion in the official repository.
> *) I've been wondering why GIT lacks a "update", ie
> pull-without-merge command. You almost never want
> to git pull /without/ -r?
-r stands for "rebase", i.e. it makes git pull use rebase instead of
merge. Rebase has certain problematic implications for decentralized
development, which is why it should only really be used in specific
circumstances (for rebasing commits that haven't been published in any
way yet).
"You" may almost never want to use git pull without rebase, but "many
others" do, and very often. Personally, I donn't recall a single
occasion where I have used git pull --rebase (not counting git-svn
stuff).
Anyway, look at config options branch.autosetuprebase and
branch.<nickname>.rebase to see how you can make pull use rebase by
default.
-Jan
^ 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