* [JGIT PATCH 2/2] Improve closing of files in error situations.
From: Robin Rosenberg @ 2008-12-02 21:20 UTC (permalink / raw)
To: spearce; +Cc: git, Robin Rosenberg
In-Reply-To: <1228252816-5987-1-git-send-email-robin.rosenberg@dewire.com>
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
.../exttst/org/spearce/jgit/lib/SpeedTestBase.java | 12 +++++--
.../src/org/spearce/jgit/lib/Repository.java | 31 +++++++++++++-------
2 files changed, 28 insertions(+), 15 deletions(-)
diff --git a/org.spearce.jgit.test/exttst/org/spearce/jgit/lib/SpeedTestBase.java b/org.spearce.jgit.test/exttst/org/spearce/jgit/lib/SpeedTestBase.java
index 11f7439..36a5e0e 100644
--- a/org.spearce.jgit.test/exttst/org/spearce/jgit/lib/SpeedTestBase.java
+++ b/org.spearce.jgit.test/exttst/org/spearce/jgit/lib/SpeedTestBase.java
@@ -72,10 +72,14 @@
protected void prepare(String[] refcmd) throws Exception {
try {
BufferedReader bufferedReader = new BufferedReader(new FileReader("kernel.ref"));
- kernelrepo = bufferedReader.readLine();
- bufferedReader.close();
- timeNativeGit(kernelrepo, refcmd);
- nativeTime = timeNativeGit(kernelrepo, refcmd);
+ try {
+ kernelrepo = bufferedReader.readLine();
+ bufferedReader.close();
+ timeNativeGit(kernelrepo, refcmd);
+ nativeTime = timeNativeGit(kernelrepo, refcmd);
+ } finally {
+ bufferedReader.close();
+ }
} catch (Exception e) {
System.out.println("Create a file named kernel.ref and put the path to the Linux kernels repository there");
throw e;
diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java b/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
index b54afd5..da1494f 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
@@ -144,10 +144,13 @@ public Repository(final File d) throws IOException {
final File altFile = FS.resolve(objectsDir, "info/alternates");
if (altFile.exists()) {
BufferedReader ar = new BufferedReader(new FileReader(altFile));
- for (String alt=ar.readLine(); alt!=null; alt=ar.readLine()) {
- readObjectsDirs(FS.resolve(objectsDir, alt), ret);
+ try {
+ for (String alt=ar.readLine(); alt!=null; alt=ar.readLine()) {
+ readObjectsDirs(FS.resolve(objectsDir, alt), ret);
+ }
+ } catch (Exception e) {
+ ar.close();
}
- ar.close();
}
return ret;
}
@@ -1027,15 +1030,21 @@ public boolean isStGitMode() {
if (isStGitMode()) {
File patchDir = new File(new File(getDirectory(),"patches"),getBranch());
BufferedReader apr = new BufferedReader(new FileReader(new File(patchDir,"applied")));
- for (String patchName=apr.readLine(); patchName!=null; patchName=apr.readLine()) {
- File topFile = new File(new File(new File(patchDir,"patches"), patchName), "top");
- BufferedReader tfr = new BufferedReader(new FileReader(topFile));
- String objectId = tfr.readLine();
- ObjectId id = ObjectId.fromString(objectId);
- ret.put(id, new StGitPatch(patchName, id));
- tfr.close();
+ try {
+ for (String patchName=apr.readLine(); patchName!=null; patchName=apr.readLine()) {
+ File topFile = new File(new File(new File(patchDir,"patches"), patchName), "top");
+ BufferedReader tfr = new BufferedReader(new FileReader(topFile));
+ try {
+ String objectId = tfr.readLine();
+ ObjectId id = ObjectId.fromString(objectId);
+ ret.put(id, new StGitPatch(patchName, id));
+ } finally {
+ tfr.close();
+ }
+ }
+ } finally {
+ apr.close();
}
- apr.close();
}
return ret;
}
--
1.6.0.3.640.g6331a
^ permalink raw reply related
* [JGIT PATCH 1/2] Close a forgotten reference to the HEAD ref.
From: Robin Rosenberg @ 2008-12-02 21:20 UTC (permalink / raw)
To: spearce; +Cc: git, Robin Rosenberg
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
.../src/org/spearce/jgit/lib/Repository.java | 12 ++++++++++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java b/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
index c953531..b54afd5 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
@@ -989,9 +989,10 @@ public Ref peel(final Ref ref) {
* @return true if HEAD points to a StGit patch.
*/
public boolean isStGitMode() {
+ File file = new File(getDirectory(), "HEAD");
+ BufferedReader reader = null;
try {
- File file = new File(getDirectory(), "HEAD");
- BufferedReader reader = new BufferedReader(new FileReader(file));
+ reader = new BufferedReader(new FileReader(file));
String string = reader.readLine();
if (!string.startsWith("ref: refs/heads/"))
return false;
@@ -1007,6 +1008,13 @@ public boolean isStGitMode() {
} catch (IOException e) {
e.printStackTrace();
return false;
+ } finally {
+ try {
+ if (reader != null)
+ reader.close();
+ } catch (IOException e1) {
+ // nothing to do here
+ }
}
}
--
1.6.0.3.640.g6331a
^ permalink raw reply related
* [PATCH] gitk: Use check-buttons' -text property instead of separate labels
From: Johannes Sixt @ 2008-12-02 20:42 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
Previously the check-buttons' labels in the Preferences were separate
widgets. This had the disadvantage that in order to toggle the check-button
with the mouse the check-box had to be clicked. With this change the
check-box can also be toggled by clicking the label.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
gitk | 30 ++++++++++--------------------
1 files changed, 10 insertions(+), 20 deletions(-)
diff --git a/gitk b/gitk
index 64a873d..ee1941c 100755
--- a/gitk
+++ b/gitk
@@ -10079,15 +10079,11 @@ proc doprefs {} {
-font optionfont
spinbox $top.maxpct -from 1 -to 100 -width 4 -textvariable maxgraphpct
grid x $top.maxpctl $top.maxpct -sticky w
- frame $top.showlocal
- label $top.showlocal.l -text [mc "Show local changes"] -font optionfont
- checkbutton $top.showlocal.b -variable showlocalchanges
- pack $top.showlocal.b $top.showlocal.l -side left
+ checkbutton $top.showlocal -text [mc "Show local changes"] \
+ -font optionfont -variable showlocalchanges
grid x $top.showlocal -sticky w
- frame $top.autoselect
- label $top.autoselect.l -text [mc "Auto-select SHA1"] -font optionfont
- checkbutton $top.autoselect.b -variable autoselect
- pack $top.autoselect.b $top.autoselect.l -side left
+ checkbutton $top.autoselect -text [mc "Auto-select SHA1"] \
+ -font optionfont -variable autoselect
grid x $top.autoselect -sticky w
label $top.ddisp -text [mc "Diff display options"]
@@ -10095,20 +10091,14 @@ proc doprefs {} {
label $top.tabstopl -text [mc "Tab spacing"] -font optionfont
spinbox $top.tabstop -from 1 -to 20 -width 4 -textvariable tabstop
grid x $top.tabstopl $top.tabstop -sticky w
- frame $top.ntag
- label $top.ntag.l -text [mc "Display nearby tags"] -font optionfont
- checkbutton $top.ntag.b -variable showneartags
- pack $top.ntag.b $top.ntag.l -side left
+ checkbutton $top.ntag -text [mc "Display nearby tags"] \
+ -font optionfont -variable showneartags
grid x $top.ntag -sticky w
- frame $top.ldiff
- label $top.ldiff.l -text [mc "Limit diffs to listed paths"] -font optionfont
- checkbutton $top.ldiff.b -variable limitdiffs
- pack $top.ldiff.b $top.ldiff.l -side left
+ checkbutton $top.ldiff -text [mc "Limit diffs to listed paths"] \
+ -font optionfont -variable limitdiffs
grid x $top.ldiff -sticky w
- frame $top.lattr
- label $top.lattr.l -text [mc "Support per-file encodings"] -font optionfont
- checkbutton $top.lattr.b -variable perfile_attrs
- pack $top.lattr.b $top.lattr.l -side left
+ checkbutton $top.lattr -text [mc "Support per-file encodings"] \
+ -font optionfont -variable perfile_attrs
grid x $top.lattr -sticky w
entry $top.extdifft -textvariable extdifftool
--
1.6.0.4.763.g42102
^ permalink raw reply related
* Re: Overwrite master
From: Peter Harris @ 2008-12-02 20:28 UTC (permalink / raw)
To: Nicholas Wieland; +Cc: git
In-Reply-To: <67A24C29-12A6-43B0-95D5-70910C5F8841@gmail.com>
On Tue, Dec 2, 2008 at 3:09 PM, Nicholas Wieland wrote:
> Il giorno 02/dic/08, alle ore 17:32, Peter Harris ha scritto:
>
>> On Tue, Dec 2, 2008 at 11:10 AM, Nicholas Wieland wrote:
>>>
>>> Hi *,
>>> I need to overwrite my master branch with another branch. I've already
>>> created a backup branch of my master.
>>
>> While on master,
>> "git reset --hard <newbranch>"
>
> That's what I tried.
> Unfortunately I don't know where to go after:
>
> ngw@slicingupeyeballs ~/zooppa$ git commit
> # On branch master
> # Your branch and 'origin/master' have diverged,
> # and have 444 and 25 different commit(s) each, respectively.
> #
> nothing to commit (working directory clean)
That means your tracking branch is different from your local branch, by a lot.
> Do I have to push ? If I pull it tries to merge ...
If you push, it will be denied (non-fast-forward).
If you force push, your state will be as you expect. Be aware that
you're creating trouble for everyone else who uses 'origin' if you
force push. Also be aware that you will be undoing any changes that
anyone else has pushed to origin in the mean time.
Basically, history is history. If you don't want to cause problems for
the other users of 'origin', you may have to live with history as it
is. You won't be able to overwrite master, although you will probably
try to be more careful in the future.
Peter Harris
^ permalink raw reply
* Multiple SVN Repos Inside A Git Repo
From: Tim Sally @ 2008-12-02 20:22 UTC (permalink / raw)
To: git
Using git-svn, it is possible to have different parts of a git repo
correspond to a specific svn repo? From my understanding after reading
the documentation, you need one git repository per svn. My example is
that I'm trying to set up a git repo to version control everything
from my classes, but each class has a separate svn repo. Also, the
number of git repos I can create is limited, and I'd rather not
clutter everything up with many separate git-svn repos.
Example structure:
class/
.......... systems/
.......... algorithms/
.......... physics/
class is one central git repository, and systems, algorithms, and
physics contain data from three svn repositories. Ideally, you could
commit/update to/from each svn repo individually, or all at once.
Tim
^ permalink raw reply
* Re: [PATCH] Modified the default git help message to be grouped by topic
From: James Pickens @ 2008-12-02 20:11 UTC (permalink / raw)
To: Scott Chacon; +Cc: Junio C Hamano, Jeff King, git
In-Reply-To: <d411cc4a0812012210h4cb59974sbda71abd2c64f93b@mail.gmail.com>
On Mon, Dec 1, 2008 at 11:10 PM, Scott Chacon <schacon@gmail.com> wrote:
> Hi,
>
> On Mon, Dec 1, 2008 at 5:45 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> If this list is meant to show "the most commonly used" basics, then you
>> can trim the list somewhat. For example, "rm" and "mv" can be safely
>> discarded, "status" can be replaced with "diff", and "diff" can be removed
>> from "History Commands".
>>
>
> I sent a new patch that removes 'rm' and 'mv' and removes the
> common-cmd.h build process. I did keep the 'status' command, since in
> my personal experience people tend to like having that command.
Even though 'rm' might not be used very often, I think it's an important
enough command that it should not be removed from the 'basics' list.
AFAIK, the only other way to delete a file is 'rm file' followed by 'git
add -u' or 'git commit -a'. Imagine a git newbie trying to figure that
out.
I'm tempted to say the same thing about 'mv' as well. And FWIW, I use
'status' a lot more than I use 'diff', so I would vote to keep 'status' in
the list too.
James
^ permalink raw reply
* Re: Overwrite master
From: Nicholas Wieland @ 2008-12-02 20:09 UTC (permalink / raw)
To: Peter Harris; +Cc: git
In-Reply-To: <eaa105840812020832p395ecefdq57e62f95182a3557@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 775 bytes --]
Il giorno 02/dic/08, alle ore 17:32, Peter Harris ha scritto:
> On Tue, Dec 2, 2008 at 11:10 AM, Nicholas Wieland wrote:
>> Hi *,
>> I need to overwrite my master branch with another branch. I've
>> already
>> created a backup branch of my master.
>
> While on master,
> "git reset --hard <newbranch>"
>
> Or while on a different branch,
> git branch -D master
> git branch master <newbranch>
That's what I tried.
Unfortunately I don't know where to go after:
ngw@slicingupeyeballs ~/zooppa$ git commit
# On branch master
# Your branch and 'origin/master' have diverged,
# and have 444 and 25 different commit(s) each, respectively.
#
nothing to commit (working directory clean)
Do I have to push ? If I pull it tries to merge ...
Thanks a lot for your time,
ngw
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2435 bytes --]
^ permalink raw reply
* Re: git-p4, SyntaxError: invalid syntax
From: Jason Foreman @ 2008-12-02 19:45 UTC (permalink / raw)
To: git list
In-Reply-To: <186027.87419.qm@web37901.mail.mud.yahoo.com>
On Tue, Dec 2, 2008 at 1:08 PM, Gary Yang <garyyang6@yahoo.com> wrote:
>
> /home/gyang/bin/git-p4:161: Warning: 'yield' will become a reserved keyword in the future
> File "/user/svdc/pluo/bin/git-p4", line 161
> yield pattern
> ^
> SyntaxError: invalid syntax
>
This seems to indicate that your python doesn't support the "yield"
keyword (used in generators).
Are you using Python 2.2? If so, that is a very old Python and I'd
recommend upgrading. But even with 2.2 you can fix this by adding the
following import line:
from __future__ import generators
I'm not familiar with the git-p4 file specifically but the above
should hopefully fix your problem.
Cheers,
Jason
^ permalink raw reply
* git-p4, SyntaxError: invalid syntax
From: Gary Yang @ 2008-12-02 19:08 UTC (permalink / raw)
To: git list
I got git-p4 from “git clone git://git.kernel.org/pub/scm/git/git.git git”
I copied git-p4 from contrib/fast-import/git-p4 to /home/gyang/bin
I got SyntaxError when I ran,
git-p4 clone //depot/Workshop
/home/gyang/bin/git-p4:161: Warning: 'yield' will become a reserved keyword in the future
File "/user/svdc/pluo/bin/git-p4", line 161
yield pattern
^
SyntaxError: invalid syntax
I opened the file, git-p4. There are three import lines. I am not python programmer. Maybe I missed something in python? I have python installed at /usr/local/bin/python
which python
/usr/local/bin/python
vi git-p4
import optparse, sys, os, marshal, popen2, subprocess, shelve
import tempfile, getopt, sha, os.path, time, platform
import re
Can someone tell me what I missed?
Thanks.
^ permalink raw reply
* Re: Managing websites with git
From: Junio C Hamano @ 2008-12-02 19:07 UTC (permalink / raw)
To: Jeff King; +Cc: Jason Riedy, git
In-Reply-To: <20081202165507.GA15826@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Tue, Dec 02, 2008 at 10:55:34AM -0500, Jason Riedy wrote:
>
>> Ah, ok, thanks! Issuing a warning makes sense. I'm not sure if
>> denying such a push by default does...
> ...
> It shouldn't make you change how you work. At most, it will break an
> existing setup until you set receive.denycurrentbranch to false (again,
> if and when the default value changes). You can prepare for any such
> change now by pre-emptively setting the config value.
True.
But "pre-emptively" is a bit misleading. Please realize that the warning
is not about "this is a risky thing to do, you've been warned", but is
about "the behaviour to allow this may change in the future; if you rely
on it please set this config before that happens". We may end up not
flipping the default for a long time, but setting the config also has the
side effect of squelching the warning, so it never hurts to set it now.
^ permalink raw reply
* Re: Grafting mis-aligned trees.
From: Boyd Stephen Smith Jr. @ 2008-12-02 18:28 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <493572A3.4070205@drmicha.warpmail.net>
[-- Attachment #1: Type: text/plain, Size: 2327 bytes --]
On Tuesday 02 December 2008, Michael J Gruber <git@drmicha.warpmail.net>
wrote about 'Re: Grafting mis-aligned trees.':
>Boyd Stephen Smith Jr. venit, vidit, dixit 02.12.2008 18:19:
>> I can't help thinking that rebase -ip might have helped. I wasn't
>> aware of -p when I was initially working on this problem. (It doesn't
>> help that I generally use Debian stable, and git 1.4 did not have -p.)
>
>rebase rebases one branch at a time, but you need to rebase/rewrite
>several, and the merge info between depends on rewritten sha1s.
Yes. I guess that's why I employed filter-branch to begin with.
>> I probably don't need the -f. If there are files that should be
>> ignored (and thus shouldn't be in the repo), I'll filter-branch to cut
>> them out of the history at some point.
>
>'-f' is about not having to clean out refs/original from a previous
>filter-branch run.
Okay, I misread your command line. For some reason I thought "-f" was an
option to add.
>> What *exactly* is the subtree merge. The documentation I've read
>> sounds like this case, sort of, but it's rather unclear to me.
>
>I think 'subtree' does what you want, but 'merge' doesn't!
*giggle* I'm not quite sure what makes this funny to me, but it made me
laugh.
>'subtree'
>saves you the rewriting (putting TI into project/web), but you want a
>one-time conversion anyway. 'subtree' allows you to repeatedly merge
>branches with a different root. What it does is it looks for subdir,
>'rewrites' the incoming tree automatically and merges the result.
>
>But you don't want a merge, do you? Or else your whole TI history would
>be tacked onto FT's head "to the left": a new (subtree) merge commit
>would have FT's and TI's head as parents. This is one way of storing TI
>history in the full repo, but not the one you said you wanted.
You are right; that's not what I want. But, it is a good second-place
result that I'll keep in mind. Sometimes keeping the history at all is
more important that keeping the history orderly.
Again, thanks for the help.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss03@volumehost.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.org/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Branch name with space
From: Shawn O. Pearce @ 2008-12-02 18:03 UTC (permalink / raw)
To: Le; +Cc: git
In-Reply-To: <4935719A.8000705@distributel.ca>
Le <le_wen@distributel.ca> wrote:
> I tried to rename a branch to a new name with space in it. It complained :
> git-branch -M 'test 1' or test\ 1
> fatal: Invalid branch name: refs/heads/test 1
>
> Is there a way the get round this problem?
Don't put spaces in branch names. They aren't permitted. Use
an underscore ('_') or a hypen ('-').
--
Shawn.
^ permalink raw reply
* Re: Bugs in git-gui and git-push when pushing src:dst to mirror?
From: Mark Burton @ 2008-12-02 17:49 UTC (permalink / raw)
To: git
In-Reply-To: <20081202130859.43ba54f6@crow>
On Tue, 2 Dec 2008 13:08:59 +0000
Mark Burton <markb@ordern.com> wrote:
> The other issue is that although git-push did print the usage blurb,
> it didn't actually produce a message saying what it's problem was.
Ah, just twigged, 1.6.0.4 doesn't include b259f09b181c (Make push more
verbose about illegal combination of options) so the lack of error message
from push is understandable.
Cheers,
Mark
^ permalink raw reply
* Branch name with space
From: Le @ 2008-12-02 17:34 UTC (permalink / raw)
To: git
Hi, there,
I tried to rename a branch to a new name with space in it. It complained :
git-branch -M 'test 1' or test\ 1
fatal: Invalid branch name: refs/heads/test 1
Is there a way the get round this problem?
Thanks!
Le
^ permalink raw reply
* Re: Grafting mis-aligned trees.
From: Michael J Gruber @ 2008-12-02 17:38 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: git
In-Reply-To: <200812021119.51857.bss03@volumehost.net>
Boyd Stephen Smith Jr. venit, vidit, dixit 02.12.2008 18:19:
...
> It does feel a bit "hacky", I was hoping git would have better support
> this, through the subtree merge or something else. It seems like
> something that might happen to others, perhaps as a side-effect of a
> failed attempt at using submodules.
Well, except for 'tar' my solution uses only git commands ;)
> I can't help thinking that rebase -ip might have helped. I wasn't aware
> of -p when I was initially working on this problem. (It doesn't help that
> I generally use Debian stable, and git 1.4 did not have -p.)
rebase rebases one branch at a time, but you need to rebase/rewrite
several, and the merge info between depends on rewritten sha1s.
...
> I probably don't need the -f. If there are files that should be ignored
> (and thus shouldn't be in the repo), I'll filter-branch to cut them out of
> the history at some point.
'-f' is about not having to clean out refs/original from a previous
filter-branch run.
> What *exactly* is the subtree merge. The documentation I've read sounds
> like this case, sort of, but it's rather unclear to me.
I think 'subtree' does what you want, but 'merge' doesn't! 'subtree'
saves you the rewriting (putting TI into project/web), but you want a
one-time conversion anyway. 'subtree' allows you to repeatedly merge
branches with a different root. What it does is it looks for subdir,
'rewrites' the incoming tree automatically and merges the result.
But you don't want a merge, do you? Or else your whole TI history would
be tacked onto FT's head "to the left": a new (subtree) merge commit
would have FT's and TI's head as parents. This is one way of storing TI
history in the full repo, but not the one you said you wanted.
Michael
^ permalink raw reply
* Re: [PATCH] Modifies the default git help message to be grouped by topic
From: Jeff King @ 2008-12-02 17:28 UTC (permalink / raw)
To: Scott Chacon; +Cc: gitster, git
In-Reply-To: <20081202172025.GB15826@coredump.intra.peff.net>
On Tue, Dec 02, 2008 at 12:20:25PM -0500, Jeff King wrote:
> Sorry to reverse direction after you resubmitted, but my earlier comment
> on "this list shouldn't change frequently" didn't take into account that
> the _synopsis_ might change, which is much more likely. So maybe rather
> than ditching the auto-generation, it makes sense to just hardcode the
> order and categorization, but pull the rest from autogeneration.
Note also that one could of course just use "common:basic" or something
like that in command-list.txt. But to handle arbitrary ordering, we
would have to reorder command-list as appropriate (which currently gets
sorted), or do something awful like common:basic1, common:basic2, etc. I
tried to choose the most straightforward approach that didn't involve
duplication of information.
-Peff
^ permalink raw reply
* Re: [PATCH] Modifies the default git help message to be grouped by topic
From: Jeff King @ 2008-12-02 17:20 UTC (permalink / raw)
To: Scott Chacon; +Cc: gitster, git
In-Reply-To: <20081202060509.GA48796@agadorsparticus>
On Mon, Dec 01, 2008 at 10:05:09PM -0800, Scott Chacon wrote:
> - sed -n '
> - /NAME/,/git-'"$cmd"'/H
> - ${
> - x
> - s/.*git-'"$cmd"' - \(.*\)/ {"'"$cmd"'", "\1"},/
> - p
> - }' "Documentation/git-$cmd.txt"
Sorry to reverse direction after you resubmitted, but my earlier comment
on "this list shouldn't change frequently" didn't take into account that
the _synopsis_ might change, which is much more likely. So maybe rather
than ditching the auto-generation, it makes sense to just hardcode the
order and categorization, but pull the rest from autogeneration.
Something like the patch below (though it makes the 'common' tag in
command-list.txt somewhat redundant, so we should probably just remove
that):
diff --git a/builtin-help.c b/builtin-help.c
index f076efa..b5eafb7 100644
--- a/builtin-help.c
+++ b/builtin-help.c
@@ -275,6 +275,15 @@ static int git_help_config(const char *var, const char *value, void *cb)
static struct cmdnames main_cmds, other_cmds;
+static const char *find_cmdname_help(const char *name)
+{
+ int i;
+ for (i = 0; i < ARRAY_SIZE(common_cmds); i++)
+ if (!strcmp(common_cmds[i].name, name))
+ return common_cmds[i].help;
+ return "";
+}
+
void list_common_cmds_help(void)
{
int i, longest = 0;
@@ -285,11 +294,43 @@ void list_common_cmds_help(void)
}
puts("The most commonly used git commands are:");
- for (i = 0; i < ARRAY_SIZE(common_cmds); i++) {
- printf(" %s ", common_cmds[i].name);
- mput_char(' ', longest - strlen(common_cmds[i].name));
- puts(common_cmds[i].help);
- }
+
+#define COMMON(x) \
+do { \
+ printf(" %s ", x); \
+ mput_char(' ', longest - strlen(x)); \
+ puts(find_cmdname_help(x)); \
+} while(0)
+
+ puts("Basic Commands");
+ COMMON("init");
+ COMMON("add");
+ COMMON("status");
+ COMMON("commit");
+ puts("");
+
+ puts("History Commands");
+ COMMON("log");
+ COMMON("diff");
+ COMMON("reset");
+ COMMON("show");
+ puts("");
+
+ puts("Branch Commands");
+ COMMON("checkout");
+ COMMON("branch");
+ COMMON("merge");
+ COMMON("rebase");
+ COMMON("tag");
+ puts("");
+
+ puts("Remote Commands");
+ COMMON("clone");
+ COMMON("fetch");
+ COMMON("pull");
+ COMMON("push");
+
+#undef COMMON
}
static int is_git_command(const char *s)
^ permalink raw reply related
* Re: Grafting mis-aligned trees.
From: Boyd Stephen Smith Jr. @ 2008-12-02 17:19 UTC (permalink / raw)
To: git; +Cc: Michael J Gruber
In-Reply-To: <4935606A.8050906@drmicha.warpmail.net>
[-- Attachment #1: Type: text/plain, Size: 3605 bytes --]
On Tuesday 02 December 2008, Michael J Gruber <git@drmicha.warpmail.net>
wrote about 'Re: Grafting mis-aligned trees.':
>Boyd Stephen Smith Jr. venit, vidit, dixit 29.11.2008 00:01:
>> On Tuesday 2008 November 18 03:24, Michael J Gruber wrote:
>>> Boyd Stephen Smith Jr. venit, vidit, dixit 17.11.2008 23:45:
>>>> Trees look something like this right now.
>>>>
>>>> <some history> -> FT
>>>>
>>>> TI -> <non-linear history> -> A -> <non-linear history> -> C
>>>> \ \ \
>>>> -> PI ------------------------> B ------------------------> D
>>>>
>>>> I'd like to have it look something like:
>>>>
>>>> <some history> -> FT -> <non-linear history> -> A' -> <non-linear
>>>> history> -> C' \ \
>>>> \ -> PI' ----------------------> B' -----------------------> D'
>>>>
>>>> A', B', C', and D' are different commits, but the diff (and history)
>>>> between FT and A' is the same as the diff (and history) between TI
>>>> and A.
>>>
>>> So, your base directory for TI and FT is different, right? I.e.: In
>>> the TI repo, your project sits at the root, whereas in the FT repo it
>>> sits in project/web?
>>
>> Yes.
>>
>>> Has FT advanced since you took the initial subdir
>>> snapshot for TI?
>>
>> No.
>
>OK, here's a possibly primitive solution, but it works with my little
>toy model of your layout:
That sounds like it will work fine. Thank you very much.
It does feel a bit "hacky", I was hoping git would have better support
this, through the subtree merge or something else. It seems like
something that might happen to others, perhaps as a side-effect of a
failed attempt at using submodules.
I can't help thinking that rebase -ip might have helped. I wasn't aware
of -p when I was initially working on this problem. (It doesn't help that
I generally use Debian stable, and git 1.4 did not have -p.)
>- filter-branch your TI branches so that they are in the proper subdir
>(you did that already)
If I need to "undo" this, it's really easy.
>- take a snapshot (say ftstuff.tar) of everything in FT's head (assuming
>this is where TI branched off, or else take that point) *but exclude
>project/web*
>
>- using filter-branch again, rewrite your TI branches to contain those
>missing FT files:
>git filter-branch --tree-filter 'tar -xf /tmp/ftstuff.tar && git add .'
>-f -- ti/master ti/whatever
I probably don't need the -f. If there are files that should be ignored
(and thus shouldn't be in the repo), I'll filter-branch to cut them out of
the history at some point.
Now is as good a time as any.
>Now your TI branches produce the same diffs as before, but are based on
>the full tree. You can happily graft FT's head onto TI's root as a
> parent. In fact those two should produce no diff in between them, so you
> might as well get rid of one of them.
Makes sense.
>[cleaning out refs/original and repack -adf might be in order afterwards]
I generally do these after a successful filter-branch.
>The tree-filter part feels hacky but does the job (probably with -f). I
>don't think a subtree merge can do what you want.
What *exactly* is the subtree merge. The documentation I've read sounds
like this case, sort of, but it's rather unclear to me.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss03@volumehost.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.org/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Managing websites with git
From: Jeff King @ 2008-12-02 16:55 UTC (permalink / raw)
To: Jason Riedy; +Cc: git
In-Reply-To: <87vdu2po5l.fsf@sparse.dyndns.org>
On Tue, Dec 02, 2008 at 10:55:34AM -0500, Jason Riedy wrote:
> Ah, ok, thanks! Issuing a warning makes sense. I'm not sure if
> denying such a push by default does...
I don't know if Junio has made a decision on whether or when the default
should be flipped to 'deny'.
> > Doing git push $remote HEAD:branch-that-is-checked-out
> > has _never_ worked without further action on $remote. Now we're warning
> > about it.
>
> It works just fine. I suspect we have different definitions of
> "works".
Fair enough. To be more precise: such a push has always resulted in a
state on the remote end that the user must be aware of when making
further commits, and the result of _not_ being aware and blindly running
"git commit" is to accidentally revert all of the pushed changes. And
even if one _is_ aware, sorting out any existing changes in the index
from pushed changes can be difficult.
So yes, there are workflows that can legitimately make use of a push to
the current branch. But it is still a dangerous operation for a large
number of users (I would argue the majority, but I don't have actual
numbers) that we have seen numerous complaints about.
> To me, that push updates the branch's reference. The working
> copy and index now may be out of sync, but neither the working
> copy nor the index is the branch's reference. Trying to commit
> from the index correctly refuses. The warning is a nice
How is committing from the index refused? Try this:
mkdir parent &&
(cd parent &&
git init &&
echo content >file &&
git add file &&
git commit -m one) &&
git clone parent child &&
(cd child &&
echo changes >>file &&
git commit -a -m two &&
git push) &&
(cd parent &&
git commit -m oops &&
git show
)
You will find that you have just reverted the changes from 'two' with
'oops'.
Committing straight from the working tree (via "git commit <path>" or
"git commit -a") has the same problem.
> (And in context: I used to update the IEEE754 group's web site by
> a git push to the checked-out master, with a hook to reset
> everything. Worked just fine (and very quickly) until they shut
> off shell access. There was no need for an extra branch on the
> server side.)
Follow the earlier parts of the thread and you will see that is one of
the sane workflows that has been mentioned. You are aware of the lack of
sync (and you have a hook to address it) and you don't plan on having
any local changes (so sorting them out is easy -- you just "git reset
--hard" to take the pushed content).
> I'll try to find time when I encounter another. I'm pretty sure
> that switching to denying pushes to checked-out branches is the
> first one that *really* will make me change how I work.
It shouldn't make you change how you work. At most, it will break an
existing setup until you set receive.denycurrentbranch to false (again,
if and when the default value changes). You can prepare for any such
change now by pre-emptively setting the config value.
-Peff
^ permalink raw reply
* [man bug?] git rebase --preserve-merges
From: Constantine Plotnikov @ 2008-12-02 16:45 UTC (permalink / raw)
To: git
The man page for git rebase mentions "--preserve-merges" command line
option but this option does not seems to be available.
Also if this option is specified, the following usage statement is printed:
Usage: git rebase [--interactive | -i] [-v] [--onto <newbase>]
<upstream> [<branch>]
And this usage statement does not mention -m and -s options that seems
to be available. I assume that the problem is the obsolete
documentation.
Regards,
Constantine
^ permalink raw reply
* Re: [JGIT PATCH v2 0/8] Unit test cleanups
From: Shawn O. Pearce @ 2008-12-02 16:38 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git, fonseca
In-Reply-To: <1228088435-23722-1-git-send-email-robin.rosenberg@dewire.com>
Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
> A completele reworked set of patches, including fixing a couple
> more forgot-to-close bugs and Shawns suggestion that we disable
> memory mapping in junit tests by default.
...
> Robin Rosenberg (8):
> Drop unneeded code in unit tests
> Cleanup malformed test cases
> Turn off memory mapping in JGit unit tests by default
> Add a counter to make sure the test repo name is unique
> Make the cleanup less verbose when it fails to delete temporary
> stuff.
> Cleanup after each test.
> Close files opened by unit testing framework
> Hard failure on unit test cleanups if they fail.
>
> .../tst/org/spearce/jgit/lib/PackWriterTest.java | 3 +
> .../org/spearce/jgit/lib/RepositoryTestCase.java | 152 +++++++++++++++++---
> .../tst/org/spearce/jgit/lib/T0007_Index.java | 10 +-
> 3 files changed, 139 insertions(+), 26 deletions(-)
Merged. The series looked really good to me. Second time is the
charm, eh? :-)
--
Shawn.
^ permalink raw reply
* Re: Managing websites with git
From: Jason Riedy @ 2008-12-02 15:55 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20081202011154.GA6390@coredump.intra.peff.net>
And Jeff King writes:
> To clarify: one should not push to the _current branch_ of a
> non-bare repo...
Ah, ok, thanks! Issuing a warning makes sense. I'm not sure if
denying such a push by default does...
> Doing git push $remote HEAD:branch-that-is-checked-out
> has _never_ worked without further action on $remote. Now we're warning
> about it.
It works just fine. I suspect we have different definitions of
"works".
To me, that push updates the branch's reference. The working
copy and index now may be out of sync, but neither the working
copy nor the index is the branch's reference. Trying to commit
from the index correctly refuses. The warning is a nice
reminder, but I don't see why this should be denied by default.
The user (me) hasn't lost anything, and every tool does what it
is supposed to do (from my point of view).
But I'm one of those people who has always liked the three levels
of git. And I use them all.
(And in context: I used to update the IEEE754 group's web site by
a git push to the checked-out master, with a hook to reset
everything. Worked just fine (and very quickly) until they shut
off shell access. There was no need for an extra branch on the
server side.)
> If you have other specific complaints about new git behavior,
> I'm sure the list would be happy to hear about it.
I'll try to find time when I encounter another. I'm pretty sure
that switching to denying pushes to checked-out branches is the
first one that *really* will make me change how I work.
Jason
^ permalink raw reply
* Re: Overwrite master
From: Peter Harris @ 2008-12-02 16:32 UTC (permalink / raw)
To: Nicholas Wieland; +Cc: git
In-Reply-To: <D1AC0A41-E89A-4B53-A449-DA9C4422998E@zooppa.com>
On Tue, Dec 2, 2008 at 11:10 AM, Nicholas Wieland wrote:
> Hi *,
> I need to overwrite my master branch with another branch. I've already
> created a backup branch of my master.
While on master,
"git reset --hard <newbranch>"
Or while on a different branch,
git branch -D master
git branch master <newbranch>
Peter Harris
^ permalink raw reply
* Re: [PATCH] git-gui: Teach start_push_anywhere_action{} to notice when remote is a mirror.
From: Mark Burton @ 2008-12-02 16:31 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20081202153007.GJ23984@spearce.org>
Hi Shawn,
> Yea, it is a chunk of work. I thought about trying to do it myself
> right now, but realized I won't be able to do it in 15 minutes and
> gave up. :-)
Well, when you/someone looks at updating the push dialog you could
consider adding another checkbox that disables the refspec so that the
push uses whatever default refspec has been configured. I think that would
be a useful addition.
Cheers,
Mark
^ permalink raw reply
* Re: Grafting mis-aligned trees.
From: Michael J Gruber @ 2008-12-02 16:20 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: git
In-Reply-To: <200811281701.46778.bss03@volumehost.net>
Boyd Stephen Smith Jr. venit, vidit, dixit 29.11.2008 00:01:
> On Tuesday 2008 November 18 03:24, Michael J Gruber wrote:
>> Boyd Stephen Smith Jr. venit, vidit, dixit 17.11.2008 23:45:
>>> I haven't gotten a response from my subscription email, so please CC me
>>> on any replies.
>>>
>>> So, I've been managaing the source I had from a client project in git and
>>> have a non-linear history. Currently, two tips (production and testing)
>>> but there are many feature branches that were git-merge'd in, not
>>> rebased.
>>>
>>> Now, I've gotten the full tree. Turns out all the source code I was
>>> working on was in a subdirectory "project/web". I'd like to "graft" the
>>> *changes* I made onto the full tree.
>>>
>>> I figured this might be a job for git-filter-branch. Certainly, that did
>>> the job of moving all my changes into the subdirectory. But, now I want
>>> to do something that's a combination or git-rebase and git-filter-branch.
>>> I want to replay the *patches/deltas* (like rebase) on top of the full
>>> tree I have, but *maintain the non-liear history* (like filter-branch).
>>>
>>> Can anyone think of a recipe for me?
>>>
>>> Trees look something like this right now.
>>>
>>> <some history> -> FT
>>>
>>> TI -> <non-linear history> -> A -> <non-linear history> -> C
>>> \ \ \
>>> -> PI ------------------------> B ------------------------> D
>>>
>>> I'd like to have it look something like:
>>>
>>> <some history> -> FT -> <non-linear history> -> A' -> <non-linear
>>> history> -> C' \ \ \
>>> -> PI' ----------------------> B' -----------------------> D'
>>>
>>> A', B', C', and D' are different commits, but the diff (and history)
>>> between FT and A' is the same as the diff (and history) between TI and A.
>>>
>>> Again, please CC me on any replies.
>> [CCing is customary here anyways.]
>>
>> So, your base directory for TI and FT is different, right? I.e.: In the
>> TI repo, your project sits at the root, whereas in the FT repo it sits
>> in project/web?
>
> Yes.
>
>> Has FT advanced since you took the initial subdir
>> snapshot for TI?
>
> No. Well, maybe. I think the subdir diff is fairly trivial if not empty. TI
> is an import from the code actually present on the testing server. FT was
> the a subversion repository obtained later after some hullabaloo with the
> ex-development house.
>
> Right now this tree is effectively all mine, so I can always graft in commits
> to synchronize the common subtree of FT and TI, if that makes things easier.
OK, here's a possibly primitive solution, but it works with my little
toy model of your layout:
- filter-branch your TI branches so that they are in the proper subdir
(you did that already)
- take a snapshot (say ftstuff.tar) of everything in FT's head (assuming
this is where TI branched off, or else take that point) *but exclude
project/web*
- using filter-branch again, rewrite your TI branches to contain those
missing FT files:
git filter-branch --tree-filter 'tar -xf /tmp/ftstuff.tar && git add .'
-f -- ti/master ti/whatever
Now your TI branches produce the same diffs as before, but are based on
the full tree. You can happily graft FT's head onto TI's root as a parent.
In fact those two should produce no diff in between them, so you might
as well get rid of one of them.
[cleaning out refs/original and repack -adf might be in order afterwards]
The tree-filter part feels hacky but does the job (probably with -f). I
don't think a subtree merge can do what you want.
Cheers,
Michael
^ 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