* Re: [PATCH] filter-branch: add git_commit_non_empty_tree and --prune-empty.
From: Pierre Habouzit @ 2009-01-11 14:27 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jay Soffian, Junio C Hamano, git, pasky, srabbelier
In-Reply-To: <alpine.DEB.1.00.0901111433580.3586@pacific.mpi-cbg.de>
[-- Attachment #1: Type: text/plain, Size: 1514 bytes --]
On Sun, Jan 11, 2009 at 01:35:15PM +0000, Johannes Schindelin wrote:
> Hi,
>
> On Sun, 11 Jan 2009, Pierre Habouzit wrote:
>
> > On Fri, Jan 09, 2009 at 07:29:15PM +0000, Jay Soffian wrote:
> > > On Mon, Nov 3, 2008 at 10:18 AM, Pierre Habouzit <madcoder@debian.org> wrote:
> > > > On Mon, Nov 03, 2008 at 09:27:29AM +0000, Pierre Habouzit wrote:
> > > >> On Mon, Nov 03, 2008 at 04:58:44AM +0000, Junio C Hamano wrote:
> > >
> > > Bump, http://thread.gmane.org/gmane.comp.version-control.git/99440/
> > >
> > > (I'd like to see this included. Having a bunch of empty commits after
> > > using filter-branch to remove unwanted files from history is, er,
> > > sub-optimal, so seems like it might even be default behavior?)
> >
> > Yeah I have that in my own git tree, and I meant to ask if something had
> > to be fixed for it to be accepted for some time, but always forget about
> > it.
> >
> > Junio, do you think this could be accepted, or does it need some work ?
>
> AFAICT Junio had some style issues which were not addressed.
Huh, I did in a latter resend in that very thread.
> And I suggested to merge the tests with Sverre's patch. That suggestion
> also went unaddressed.
I can't find any mails from Sverre in the same thread, but maybe I'm not
searching in the proper place...
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2009, #02; Sun, 11)
From: Jakub Narebski @ 2009-01-11 14:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v63kmtbk6.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> ----------------------------------------------------------------
> [Actively cooking]
>
> * sc/gitweb-category (Fri Dec 12 00:45:12 2008 +0100) 3 commits
> - gitweb: Optional grouping of projects by category
> - gitweb: Split git_project_list_body in two functions
> - gitweb: Modularized git_get_project_description to be more generic
This I think needs some further cooking. I guess with addition of one
more patch to series categories could be sorted together with projects
they contain, and not always have to be in fixed ordering.
> * gb/gitweb-patch (Thu Dec 18 08:13:19 2008 +0100) 4 commits
> - gitweb: link to patch(es) view in commit(diff) and (short)log view
> - gitweb: add patches view
> - gitweb: change call pattern for git_commitdiff
> - gitweb: add patch view
If I remember correctly the only point of discussion is calling
convention for git_commitdiff, and whether 'patches' view should
(re)use git_commitdiff or use its own subroutine.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] filter-branch: add git_commit_non_empty_tree and --prune-empty.
From: Sverre Rabbelier @ 2009-01-11 14:40 UTC (permalink / raw)
To: Pierre Habouzit
Cc: Johannes Schindelin, Jay Soffian, Junio C Hamano, git, pasky
In-Reply-To: <20090111142732.GA18484@artemis.corp>
On Sun, Jan 11, 2009 at 15:27, Pierre Habouzit <madcoder@debian.org> wrote:
>> And I suggested to merge the tests with Sverre's patch. That suggestion
>> also went unaddressed.
>
> I can't find any mails from Sverre in the same thread, but maybe I'm not
> searching in the proper place...
I think my patch is in a different thread as it was a
documentation-only patch, no?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] filter-branch: add git_commit_non_empty_tree and --prune-empty.
From: Pierre Habouzit @ 2009-01-11 14:55 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Johannes Schindelin, Jay Soffian, Junio C Hamano, git, pasky
In-Reply-To: <bd6139dc0901110640l148b00dctd667572e28908f9f@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 853 bytes --]
On Sun, Jan 11, 2009 at 02:40:04PM +0000, Sverre Rabbelier wrote:
> On Sun, Jan 11, 2009 at 15:27, Pierre Habouzit <madcoder@debian.org> wrote:
> >> And I suggested to merge the tests with Sverre's patch. That suggestion
> >> also went unaddressed.
> >
> > I can't find any mails from Sverre in the same thread, but maybe I'm not
> > searching in the proper place...
>
> I think my patch is in a different thread as it was a
> documentation-only patch, no?
No I've found it, it was sent by Petr which explains why I didn't find a
mail from _you_ :P
Will sent a patch reworked to have a special paragraph the way you
wanted, but using my additions instead.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* current git kernel has strange problems during bisect
From: Christian Borntraeger @ 2009-01-11 15:02 UTC (permalink / raw)
To: git; +Cc: Linux Kernel Mailing List
doing a
git bisect start
git bisect good a3a798c
git bisect bad v2.6.29-rc1
results in a repository without several files, e.g Makefile!
git describe also fails.
Any ideas how to fix this problem to continue with my bisect?
Christian
^ permalink raw reply
* Re: current git kernel has strange problems during bisect
From: Christian Borntraeger @ 2009-01-11 15:07 UTC (permalink / raw)
To: git; +Cc: Linux Kernel Mailing List, torvalds
In-Reply-To: <200901111602.53082.borntraeger@de.ibm.com>
Am Sonntag 11 Januar 2009 schrieb Christian Borntraeger:
> doing a
> git bisect start
> git bisect good a3a798c
> git bisect bad v2.6.29-rc1
>
> results in a repository without several files, e.g Makefile!
> git describe also fails.
In fact, retesting with a clean repository shows, that there are only btrfs
files - nothing else.
Linus did you pull a broken btrfs repository?
Christian
^ permalink raw reply
* Re: [PATCH] filter-branch: add git_commit_non_empty_tree and --prune-empty.
From: Sverre Rabbelier @ 2009-01-11 15:08 UTC (permalink / raw)
To: Pierre Habouzit
Cc: Johannes Schindelin, Jay Soffian, Junio C Hamano, git, pasky
In-Reply-To: <20090111145537.GB18484@artemis.corp>
On Sun, Jan 11, 2009 at 15:55, Pierre Habouzit <madcoder@debian.org> wrote:
> No I've found it, it was sent by Petr which explains why I didn't find a
> mail from _you_ :P
Ah, yes, that's right :).
> Will sent a patch reworked to have a special paragraph the way you
> wanted, but using my additions instead.
Ok, nice!
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: current git kernel has strange problems during bisect
From: Johannes Schindelin @ 2009-01-11 15:14 UTC (permalink / raw)
To: Christian Borntraeger; +Cc: git, Linux Kernel Mailing List, torvalds
In-Reply-To: <200901111607.59054.borntraeger@de.ibm.com>
Hi,
On Sun, 11 Jan 2009, Christian Borntraeger wrote:
> Am Sonntag 11 Januar 2009 schrieb Christian Borntraeger:
> > doing a
> > git bisect start
> > git bisect good a3a798c
> > git bisect bad v2.6.29-rc1
> >
> > results in a repository without several files, e.g Makefile!
> > git describe also fails.
>
> In fact, retesting with a clean repository shows, that there are only btrfs
> files - nothing else.
>
> Linus did you pull a broken btrfs repository?
I guess it is a subtree merge. So no, nothing went wrong
Use "git bisect skip" to skip over those.
Hth,
Dscho
^ permalink raw reply
* Re: current git kernel has strange problems during bisect
From: Christian Borntraeger @ 2009-01-11 15:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Linux Kernel Mailing List, torvalds
In-Reply-To: <alpine.DEB.1.00.0901111613250.3586@pacific.mpi-cbg.de>
Am Sonntag 11 Januar 2009 schrieben Sie:
> Hi,
>
> On Sun, 11 Jan 2009, Christian Borntraeger wrote:
>
> > Am Sonntag 11 Januar 2009 schrieb Christian Borntraeger:
> > > doing a
> > > git bisect start
> > > git bisect good a3a798c
> > > git bisect bad v2.6.29-rc1
> > >
> > > results in a repository without several files, e.g Makefile!
> > > git describe also fails.
> >
> > In fact, retesting with a clean repository shows, that there are only
btrfs
> > files - nothing else.
> >
> > Linus did you pull a broken btrfs repository?
>
> I guess it is a subtree merge. So no, nothing went wrong
>
> Use "git bisect skip" to skip over those.
I think we should really avoid merging subtrees to the linux kernel. It makes
bisecting a real PITA.
Furthermore, It is unlikely, but what if the problem is part of the 581
changesets from btrfs?
Christian
^ permalink raw reply
* [EGIT PATCH 2/2] Add a border to the refs tree in the branch dialog
From: Robin Rosenberg @ 2009-01-11 16:18 UTC (permalink / raw)
To: spearce; +Cc: git, Robin Rosenberg
In-Reply-To: <1231690736-6452-1-git-send-email-robin.rosenberg@dewire.com>
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
.../ui/internal/dialogs/BranchSelectionDialog.java | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/dialogs/BranchSelectionDialog.java b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/dialogs/BranchSelectionDialog.java
index 8859b5d..db9adf0 100644
--- a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/dialogs/BranchSelectionDialog.java
+++ b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/dialogs/BranchSelectionDialog.java
@@ -87,7 +87,7 @@ protected Composite createDialogArea(Composite base) {
parent = (Composite) super.createDialogArea(base);
parent.setLayout(GridLayoutFactory.swtDefaults().create());
new Label(parent, SWT.NONE).setText(UIText.BranchSelectionDialog_Refs);
- branchTree = new Tree(parent, SWT.NONE);
+ branchTree = new Tree(parent, SWT.BORDER);
branchTree.setLayoutData(GridDataFactory.fillDefaults().grab(true,true).hint(500, 300).create());
if (showResetType) {
--
1.6.1.rc3.56.gd0306
^ permalink raw reply related
* [EGIT PATCH 1/2] Use text resources for branch dialog and add shortcuts.
From: Robin Rosenberg @ 2009-01-11 16:18 UTC (permalink / raw)
To: spearce; +Cc: git, Robin Rosenberg
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
.../src/org/spearce/egit/ui/UIText.java | 72 +++++++++++++++
.../ui/internal/dialogs/BranchSelectionDialog.java | 92 +++++++++++---------
.../src/org/spearce/egit/ui/uitext.properties | 25 ++++++
3 files changed, 148 insertions(+), 41 deletions(-)
diff --git a/org.spearce.egit.ui/src/org/spearce/egit/ui/UIText.java b/org.spearce.egit.ui/src/org/spearce/egit/ui/UIText.java
index 124d7a0..c9610b0 100644
--- a/org.spearce.egit.ui/src/org/spearce/egit/ui/UIText.java
+++ b/org.spearce.egit.ui/src/org/spearce/egit/ui/UIText.java
@@ -760,6 +760,78 @@
/** */
public static String WindowCachePreferencePage_packedGitMMAP;
+ /** */
+ public static String BranchSelectionDialog_OkReset;
+
+ /** */
+ public static String BranchSelectionDialog_ErrorCouldNotRefreshBranchList;
+
+ /** */
+ public static String BranchSelectionDialog_ErrorCouldNotCreateNewRef;
+
+ /** */
+ public static String BranchSelectionDialog_ErrorCouldNotRefresh;
+
+ /** */
+ public static String BranchSelectionDialog_BranchSuffix_Current;
+
+ /** */
+ public static String BranchSelectionDialog_ResetType;
+
+ /** */
+ public static String BranchSelectionDialog_ResetTypeSoft;
+
+ /** */
+ public static String BranchSelectionDialog_ResetTypeMixed;
+
+ /** */
+ public static String BranchSelectionDialog_ResetTypeHard;
+
+ /** */
+ public static String BranchSelectionDialog_Tags;
+
+ /** */
+ public static String BranchSelectionDialog_RemoteBranches;
+
+ /** */
+ public static String BranchSelectionDialog_LocalBranches;
+
+ /** */
+ public static String BranchSelectionDialog_NoBranchSeletectTitle;
+
+ /** */
+ public static String BranchSelectionDialog_ReallyResetTitle;
+
+ /** */
+ public static String BranchSelectionDialog_ReallyResetMessage;
+
+ /** */
+ public static String BranchSelectionDialog_QuestionNewBranchTitle;
+
+ /** */
+ public static String BranchSelectionDialog_QuestionNewBranchMessage;
+
+ /** */
+ public static String BranchSelectionDialog_NewBranch;
+
+ /** */
+ public static String BranchSelectionDialog_ErrorAlreadyExists;
+
+ /** */
+ public static String BranchSelectionDialog_ErrorCouldNotResolve;
+
+ /** */
+ public static String BranchSelectionDialog_ErrorInvalidRefName;
+
+ /** */
+ public static String BranchSelectionDialog_OkCheckout;
+
+ /** */
+ public static String BranchSelectionDialog_NoBranchSeletectMessage;
+
+ /** */
+ public static String BranchSelectionDialog_Refs;
+
static {
initializeMessages(UIText.class.getPackage().getName() + ".uitext",
UIText.class);
diff --git a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/dialogs/BranchSelectionDialog.java b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/dialogs/BranchSelectionDialog.java
index 1641840..8859b5d 100644
--- a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/dialogs/BranchSelectionDialog.java
+++ b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/dialogs/BranchSelectionDialog.java
@@ -24,6 +24,7 @@
import org.eclipse.jface.layout.GridLayoutFactory;
import org.eclipse.jface.resource.JFaceResources;
import org.eclipse.jface.window.Window;
+import org.eclipse.osgi.util.NLS;
import org.eclipse.swt.SWT;
import org.eclipse.swt.events.DisposeEvent;
import org.eclipse.swt.events.DisposeListener;
@@ -37,12 +38,14 @@
import org.eclipse.swt.widgets.Composite;
import org.eclipse.swt.widgets.Event;
import org.eclipse.swt.widgets.Group;
+import org.eclipse.swt.widgets.Label;
import org.eclipse.swt.widgets.Listener;
import org.eclipse.swt.widgets.Shell;
import org.eclipse.swt.widgets.Tree;
import org.eclipse.swt.widgets.TreeItem;
import org.spearce.egit.core.op.ResetOperation.ResetType;
import org.spearce.egit.ui.Activator;
+import org.spearce.egit.ui.UIText;
import org.spearce.jgit.lib.Constants;
import org.spearce.jgit.lib.ObjectId;
import org.spearce.jgit.lib.RefUpdate;
@@ -56,7 +59,7 @@
private final Repository repo;
private boolean showResetType = true;
-
+
/**
* Construct a dialog to select a branch to reset to or check out
* @param parentShell
@@ -76,38 +79,38 @@ public void setShowResetType(boolean show) {
}
private Composite parent;
-
+
private Tree branchTree;
-
+
@Override
protected Composite createDialogArea(Composite base) {
parent = (Composite) super.createDialogArea(base);
parent.setLayout(GridLayoutFactory.swtDefaults().create());
-
+ new Label(parent, SWT.NONE).setText(UIText.BranchSelectionDialog_Refs);
branchTree = new Tree(parent, SWT.NONE);
branchTree.setLayoutData(GridDataFactory.fillDefaults().grab(true,true).hint(500, 300).create());
-
+
if (showResetType) {
buildResetGroup();
}
-
+
try {
fillTreeWithBranches(null);
} catch (IOException e) {
- Activator.logError("Could not refresh list of branches", e);
+ Activator.logError(UIText.BranchSelectionDialog_ErrorCouldNotRefresh, e);
}
-
+
return parent;
}
private void buildResetGroup() {
Group g = new Group(parent, SWT.NONE);
- g.setText("Reset Type");
+ g.setText(UIText.BranchSelectionDialog_ResetType);
g.setLayoutData(GridDataFactory.swtDefaults().align(SWT.CENTER, SWT.CENTER).create());
g.setLayout(new RowLayout(SWT.VERTICAL));
Button soft = new Button(g, SWT.RADIO);
- soft.setText("Soft (Index and working directory unmodified)");
+ soft.setText(UIText.BranchSelectionDialog_ResetTypeSoft);
soft.addListener(SWT.Selection, new Listener() {
public void handleEvent(Event event) {
resetType = ResetType.SOFT;
@@ -116,7 +119,7 @@ public void handleEvent(Event event) {
Button medium = new Button(g, SWT.RADIO);
medium.setSelection(true);
- medium.setText("Mixed (working directory unmodified)");
+ medium.setText(UIText.BranchSelectionDialog_ResetTypeMixed);
medium.addListener(SWT.Selection, new Listener() {
public void handleEvent(Event event) {
resetType = ResetType.MIXED;
@@ -124,7 +127,7 @@ public void handleEvent(Event event) {
});
Button hard = new Button(g, SWT.RADIO);
- hard.setText("Hard");
+ hard.setText(UIText.BranchSelectionDialog_ResetTypeHard);
hard.addListener(SWT.Selection, new Listener() {
public void handleEvent(Event event) {
resetType = ResetType.HARD;
@@ -137,12 +140,12 @@ private void fillTreeWithBranches(String select) throws IOException {
List<String> branches = new ArrayList<String>(repo.getAllRefs()
.keySet());
Collections.sort(branches);
-
+
TreeItem curItem = null;
TreeItem curSubItem = null;
String curPrefix = null;
String curSubPrefix = null;
-
+
for (String ref : branches) {
String shortName = ref;
if (ref.startsWith(Constants.R_HEADS)) {
@@ -152,18 +155,18 @@ private void fillTreeWithBranches(String select) throws IOException {
curSubPrefix = null;
curSubItem = null;
curItem = new TreeItem(branchTree, SWT.NONE);
- curItem.setText("Local Branches");
+ curItem.setText(UIText.BranchSelectionDialog_LocalBranches);
}
} else if (ref.startsWith(Constants.R_REMOTES)) {
shortName = ref.substring(13);
if (!Constants.R_REMOTES.equals(curPrefix)) {
curPrefix = Constants.R_REMOTES;
curItem = new TreeItem(branchTree, SWT.NONE);
- curItem.setText("Remote Branches");
+ curItem.setText(UIText.BranchSelectionDialog_RemoteBranches);
curSubItem = null;
curSubPrefix = null;
- }
-
+ }
+
int slashPos = shortName.indexOf("/");
if (slashPos > -1) {
String remoteName = shortName.substring(0, slashPos);
@@ -184,7 +187,7 @@ private void fillTreeWithBranches(String select) throws IOException {
curSubPrefix = null;
curSubItem = null;
curItem = new TreeItem(branchTree, SWT.NONE);
- curItem.setText("Tags");
+ curItem.setText(UIText.BranchSelectionDialog_Tags);
}
}
TreeItem item;
@@ -195,7 +198,7 @@ else if (curSubItem == null)
else item = new TreeItem(curSubItem, SWT.NONE);
item.setData(ref);
if (ref.equals(branch)) {
- item.setText(shortName + " (current)");
+ item.setText(shortName + UIText.BranchSelectionDialog_BranchSuffix_Current);
FontData fd = item.getFont().getFontData()[0];
fd.setStyle(fd.getStyle() | SWT.BOLD);
final Font f = new Font(getShell().getDisplay(), fd);
@@ -212,9 +215,9 @@ public void widgetDisposed(DisposeEvent e) {
branchTree.select(item);
}
}
-
+
private String refName = null;
-
+
/**
* @return Selected ref
*/
@@ -223,32 +226,34 @@ public String getRefName() {
}
private ResetType resetType = ResetType.MIXED;
-
+
/**
* @return Type of Reset
*/
public ResetType getResetType() {
return resetType;
}
-
+
@Override
protected void okPressed() {
refNameFromDialog();
if (refName == null) {
- MessageDialog.openWarning(getShell(), "No branch/tag selected", "You must select a valid ref.");
+ MessageDialog.openWarning(getShell(),
+ UIText.BranchSelectionDialog_NoBranchSeletectTitle,
+ UIText.BranchSelectionDialog_NoBranchSeletectMessage);
return;
}
-
+
if (showResetType) {
if (resetType == ResetType.HARD) {
- if (!MessageDialog.openQuestion(getShell(), "Really reset?",
- "Resetting will overwrite any changes in your working directory.\n\n" +
- "Do you wish to continue?")) {
+ if (!MessageDialog.openQuestion(getShell(),
+ UIText.BranchSelectionDialog_ReallyResetTitle,
+ UIText.BranchSelectionDialog_ReallyResetMessage)) {
return;
}
}
}
-
+
super.okPressed();
}
@@ -266,7 +271,7 @@ protected void createButtonsForButtonBar(Composite parent) {
if (!showResetType) {
Button newButton = new Button(parent, SWT.PUSH);
newButton.setFont(JFaceResources.getDialogFont());
- newButton.setText("New branch");
+ newButton.setText(UIText.BranchSelectionDialog_NewBranch);
((GridLayout)parent.getLayout()).numColumns++;
newButton.addSelectionListener(new SelectionListener() {
@@ -276,20 +281,20 @@ public void widgetSelected(SelectionEvent e) {
InputDialog labelDialog = new InputDialog(
getShell(),
- "New branch",
- "Enter name of new branch. It will branch from the selected branch. refs/heads/ will be prepended to the name you type",
+ UIText.BranchSelectionDialog_QuestionNewBranchTitle,
+ UIText.BranchSelectionDialog_QuestionNewBranchMessage,
null, new IInputValidator() {
public String isValid(String newText) {
String testFor = Constants.R_HEADS + newText;
try {
if (repo.resolve(testFor) != null)
- return "Already exists";
+ return UIText.BranchSelectionDialog_ErrorAlreadyExists;
} catch (IOException e1) {
- Activator.logError(String.format(
- "Could not attempt to resolve %s", testFor), e1);
+ Activator.logError(NLS.bind(
+ UIText.BranchSelectionDialog_ErrorCouldNotResolve, testFor), e1);
}
if (!Repository.isValidRefName(testFor))
- return "Invalid ref name";
+ return UIText.BranchSelectionDialog_ErrorInvalidRefName;
return null;
}
});
@@ -307,14 +312,17 @@ public String isValid(String newText) {
updateRef.setNewObjectId(startAt);
updateRef.update();
} catch (IOException e1) {
- Activator.logError(String.format(
- "Could not create new ref %s", newRefName), e1);
+ Activator.logError(NLS.bind(
+ UIText.BranchSelectionDialog_ErrorCouldNotCreateNewRef,
+ newRefName), e1);
}
try {
branchTree.removeAll();
fillTreeWithBranches(newRefName);
} catch (IOException e1) {
- Activator.logError("Could not refresh list of branches",e1);
+ Activator.logError(
+ UIText.BranchSelectionDialog_ErrorCouldNotRefreshBranchList,
+ e1);
}
}
}
@@ -324,7 +332,9 @@ public void widgetDefaultSelected(SelectionEvent e) {
}
});
}
- createButton(parent, IDialogConstants.OK_ID, showResetType ? "Reset" : "Checkout", true);
+ createButton(parent, IDialogConstants.OK_ID,
+ showResetType ? UIText.BranchSelectionDialog_OkReset
+ : UIText.BranchSelectionDialog_OkCheckout, true);
createButton(parent, IDialogConstants.CANCEL_ID, IDialogConstants.CANCEL_LABEL, false);
}
diff --git a/org.spearce.egit.ui/src/org/spearce/egit/ui/uitext.properties b/org.spearce.egit.ui/src/org/spearce/egit/ui/uitext.properties
index 98ce80f..0c85378 100644
--- a/org.spearce.egit.ui/src/org/spearce/egit/ui/uitext.properties
+++ b/org.spearce.egit.ui/src/org/spearce/egit/ui/uitext.properties
@@ -288,3 +288,28 @@ WindowCachePreferencePage_packedGitWindowSize=Window size:
WindowCachePreferencePage_packedGitLimit=Window cache limit:
WindowCachePreferencePage_deltaBaseCacheLimit=Delta base cache limit:
WindowCachePreferencePage_packedGitMMAP=Use virtual memory mapping
+
+BranchSelectionDialog_BranchSuffix_Current=\ (current)
+BranchSelectionDialog_ErrorAlreadyExists=Already exists
+BranchSelectionDialog_ErrorCouldNotCreateNewRef=Could not create new ref {0}
+BranchSelectionDialog_ErrorCouldNotRefresh=Could not refresh list of branches
+BranchSelectionDialog_ErrorCouldNotRefreshBranchList=Could not refresh list of branches
+BranchSelectionDialog_ErrorCouldNotResolve=Could not attempt to resolve {0}
+BranchSelectionDialog_ErrorInvalidRefName=Invalid ref name
+BranchSelectionDialog_LocalBranches=Local Branches
+BranchSelectionDialog_NewBranch=&New branch
+BranchSelectionDialog_NoBranchSeletectMessage=You must select a valid ref.
+BranchSelectionDialog_NoBranchSeletectTitle=No branch/tag selected
+BranchSelectionDialog_OkCheckout=&Checkout
+BranchSelectionDialog_OkReset=&Reset
+BranchSelectionDialog_QuestionNewBranchMessage=Enter name of new branch. It will branch from the selected branch. refs/heads/ will be prepended to the name you type
+BranchSelectionDialog_QuestionNewBranchTitle=New branch
+BranchSelectionDialog_ReallyResetMessage=Resetting will overwrite any changes in your working directory.\n\nDo you wish to continue?
+BranchSelectionDialog_ReallyResetTitle=Really reset?
+BranchSelectionDialog_RemoteBranches=Remote Branches
+BranchSelectionDialog_ResetType=Reset Type
+BranchSelectionDialog_ResetTypeHard=&Hard
+BranchSelectionDialog_ResetTypeMixed=&Mixed (working directory unmodified)
+BranchSelectionDialog_ResetTypeSoft=&Soft (Index and working directory unmodified)
+BranchSelectionDialog_Tags=Tags
+BranchSelectionDialog_Refs=&Refs
--
1.6.1.rc3.56.gd0306
^ permalink raw reply related
* Re: current git kernel has strange problems during bisect
From: Boaz Harrosh @ 2009-01-11 16:31 UTC (permalink / raw)
To: Christian Borntraeger
Cc: Johannes Schindelin, git, Linux Kernel Mailing List, torvalds
In-Reply-To: <200901111620.03345.borntraeger@de.ibm.com>
Christian Borntraeger wrote:
> Am Sonntag 11 Januar 2009 schrieben Sie:
>> Hi,
>>
>> On Sun, 11 Jan 2009, Christian Borntraeger wrote:
>>
>>> Am Sonntag 11 Januar 2009 schrieb Christian Borntraeger:
>>>> doing a
>>>> git bisect start
>>>> git bisect good a3a798c
>>>> git bisect bad v2.6.29-rc1
>>>>
>>>> results in a repository without several files, e.g Makefile!
>>>> git describe also fails.
>>> In fact, retesting with a clean repository shows, that there are only
> btrfs
>>> files - nothing else.
>>>
>>> Linus did you pull a broken btrfs repository?
>> I guess it is a subtree merge. So no, nothing went wrong
>>
>> Use "git bisect skip" to skip over those.
>
> I think we should really avoid merging subtrees to the linux kernel. It makes
> bisecting a real PITA.
Should is too soft, we cannot. What if it changes mainline files, they will
not have common ancestry. And also the sub-tree checkout un-checkout will take
ages. Chris must have merged with his subtree with a rebase not a merge. I suspect
Linus git tree will have to rebase. This is the first time I've seen such a merge.
for example see be0e5c097f it has no parent, and so on.
> Furthermore, It is unlikely, but what if the problem is part of the 581
> changesets from btrfs?
>
Exactly
> Christian
> --
Boaz
^ permalink raw reply
* stopping patches from just floating by
From: jidanni @ 2009-01-11 17:27 UTC (permalink / raw)
To: git
I have many Documentation/* grammar patches that I can send next week.
However I fear they will be for naught, just floating by.
OK, one should keep track of the patches one sends, making sure they
are resolved one way or the other, and don't just float by.
Reviewing SubmittingPatches, in the future I will use [PATCH/RFC]
instead of just [PATCH].
I notice lots of "Merge branch qq/bla". And think, hmmm, Mr. QQ must
be using Documentation/everyday.txt's [[Individual Developer
(Participant)]] git-push methods, for a more efficient way of getting
his patches included by the maintainer.
But then I step back and look at all the [PATCH]s on this list and
conclude that just as SubmittingPatches doesn't mention git-push, the
whole git development world must be by simple emailed patches, and I
needn't bother learning git-push, making depositories on my web server
etc.
^ permalink raw reply
* [PATCH] Cleanup of unused symcache variable inside diff-lib.c
From: Kjetil Barvik @ 2009-01-11 18:36 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Kjetil Barvik
Commit c40641b77b0274186fd1b327d5dc3246f814aaaf, 'Optimize
symlink/directory detection' by Linus Torvalds, removed the 'char
*symcache' parameter to the has_symlink_leading_path() function. This
made all variables currently named 'symcache' inside diff-lib.c
unnecessary.
This also let us throw away the 'struct oneway_unpack_data', and
instead directly use the 'struct rev_info *revs' member, which
was the only member left after removal of the 'symcache[] array'
member. The 'struct oneway_unpack_data' was introduced by the
following commit:
948dd346 "diff-files: careful when inspecting work tree items"
Impact: cleanup
PATH_MAX bytes less memory stack usage in some cases
Signed-off-by: Kjetil Barvik <barvik@broadpark.no>
---
:100644 100644 ae96c64... e6d1d2b... M diff-lib.c
diff-lib.c | 40 +++++++++++-----------------------------
1 files changed, 11 insertions(+), 29 deletions(-)
diff --git a/diff-lib.c b/diff-lib.c
index ae96c64ca209f4df9008198e8a04b160bed618c7..e6d1d2b34147a13aadb5019e0c8336ef5f56ee39 100644
--- a/diff-lib.c
+++ b/diff-lib.c
@@ -61,14 +61,12 @@ int run_diff_files(struct rev_info *revs, unsigned int option)
int silent_on_removed = option & DIFF_SILENT_ON_REMOVED;
unsigned ce_option = ((option & DIFF_RACY_IS_MODIFIED)
? CE_MATCH_RACY_IS_DIRTY : 0);
- char symcache[PATH_MAX];
diff_set_mnemonic_prefix(&revs->diffopt, "i/", "w/");
if (diff_unmerged_stage < 0)
diff_unmerged_stage = 2;
entries = active_nr;
- symcache[0] = '\0';
for (i = 0; i < entries; i++) {
struct stat st;
unsigned int oldmode, newmode;
@@ -198,11 +196,6 @@ int run_diff_files(struct rev_info *revs, unsigned int option)
* diff-index
*/
-struct oneway_unpack_data {
- struct rev_info *revs;
- char symcache[PATH_MAX];
-};
-
/* A file entry went away or appeared */
static void diff_index_show_file(struct rev_info *revs,
const char *prefix,
@@ -216,8 +209,7 @@ static void diff_index_show_file(struct rev_info *revs,
static int get_stat_data(struct cache_entry *ce,
const unsigned char **sha1p,
unsigned int *modep,
- int cached, int match_missing,
- struct oneway_unpack_data *cbdata)
+ int cached, int match_missing)
{
const unsigned char *sha1 = ce->sha1;
unsigned int mode = ce->ce_mode;
@@ -248,25 +240,24 @@ static int get_stat_data(struct cache_entry *ce,
return 0;
}
-static void show_new_file(struct oneway_unpack_data *cbdata,
+static void show_new_file(struct rev_info *revs,
struct cache_entry *new,
int cached, int match_missing)
{
const unsigned char *sha1;
unsigned int mode;
- struct rev_info *revs = cbdata->revs;
/*
* New file in the index: it might actually be different in
* the working copy.
*/
- if (get_stat_data(new, &sha1, &mode, cached, match_missing, cbdata) < 0)
+ if (get_stat_data(new, &sha1, &mode, cached, match_missing) < 0)
return;
diff_index_show_file(revs, "+", new, sha1, mode);
}
-static int show_modified(struct oneway_unpack_data *cbdata,
+static int show_modified(struct rev_info *revs,
struct cache_entry *old,
struct cache_entry *new,
int report_missing,
@@ -274,9 +265,8 @@ static int show_modified(struct oneway_unpack_data *cbdata,
{
unsigned int mode, oldmode;
const unsigned char *sha1;
- struct rev_info *revs = cbdata->revs;
- if (get_stat_data(new, &sha1, &mode, cached, match_missing, cbdata) < 0) {
+ if (get_stat_data(new, &sha1, &mode, cached, match_missing) < 0) {
if (report_missing)
diff_index_show_file(revs, "-", old,
old->sha1, old->ce_mode);
@@ -344,8 +334,7 @@ static void do_oneway_diff(struct unpack_trees_options *o,
struct cache_entry *idx,
struct cache_entry *tree)
{
- struct oneway_unpack_data *cbdata = o->unpack_data;
- struct rev_info *revs = cbdata->revs;
+ struct rev_info *revs = o->unpack_data;;
int match_missing, cached;
/*
@@ -368,7 +357,7 @@ static void do_oneway_diff(struct unpack_trees_options *o,
* Something added to the tree?
*/
if (!tree) {
- show_new_file(cbdata, idx, cached, match_missing);
+ show_new_file(revs, idx, cached, match_missing);
return;
}
@@ -381,7 +370,7 @@ static void do_oneway_diff(struct unpack_trees_options *o,
}
/* Show difference between old and new */
- show_modified(cbdata, tree, idx, 1, cached, match_missing);
+ show_modified(revs, tree, idx, 1, cached, match_missing);
}
static inline void skip_same_name(struct cache_entry *ce, struct unpack_trees_options *o)
@@ -418,8 +407,7 @@ static int oneway_diff(struct cache_entry **src, struct unpack_trees_options *o)
{
struct cache_entry *idx = src[0];
struct cache_entry *tree = src[1];
- struct oneway_unpack_data *cbdata = o->unpack_data;
- struct rev_info *revs = cbdata->revs;
+ struct rev_info *revs = o->unpack_data;
if (idx && ce_stage(idx))
skip_same_name(idx, o);
@@ -446,7 +434,6 @@ int run_diff_index(struct rev_info *revs, int cached)
const char *tree_name;
struct unpack_trees_options opts;
struct tree_desc t;
- struct oneway_unpack_data unpack_cb;
mark_merge_entries();
@@ -456,14 +443,12 @@ int run_diff_index(struct rev_info *revs, int cached)
if (!tree)
return error("bad tree object %s", tree_name);
- unpack_cb.revs = revs;
- unpack_cb.symcache[0] = '\0';
memset(&opts, 0, sizeof(opts));
opts.head_idx = 1;
opts.index_only = cached;
opts.merge = 1;
opts.fn = oneway_diff;
- opts.unpack_data = &unpack_cb;
+ opts.unpack_data = revs;
opts.src_index = &the_index;
opts.dst_index = NULL;
@@ -486,7 +471,6 @@ int do_diff_cache(const unsigned char *tree_sha1, struct diff_options *opt)
struct cache_entry *last = NULL;
struct unpack_trees_options opts;
struct tree_desc t;
- struct oneway_unpack_data unpack_cb;
/*
* This is used by git-blame to run diff-cache internally;
@@ -515,14 +499,12 @@ int do_diff_cache(const unsigned char *tree_sha1, struct diff_options *opt)
if (!tree)
die("bad tree object %s", sha1_to_hex(tree_sha1));
- unpack_cb.revs = &revs;
- unpack_cb.symcache[0] = '\0';
memset(&opts, 0, sizeof(opts));
opts.head_idx = 1;
opts.index_only = 1;
opts.merge = 1;
opts.fn = oneway_diff;
- opts.unpack_data = &unpack_cb;
+ opts.unpack_data = &revs;
opts.src_index = &the_index;
opts.dst_index = &the_index;
--
1.6.1.rc1.49.g7f705
^ permalink raw reply related
* Re: git-svn: File was not found in commit
From: Morgan Christiansson @ 2009-01-11 18:36 UTC (permalink / raw)
To: Morgan Christiansson; +Cc: git
In-Reply-To: <49678705.4040506@mog.se>
Bump. Can anyone give any pointers or ideas for workarounds on this?
Searching the list archives i have found 2 others reporting similair
problems with git-svn, both which were left unreplied:
http://marc.info/?t=122118776000001&r=1&w=2
http://marc.info/?t=121537770800003&r=1&w=2
I'm stuck at this point - if i can't migrate this repository i cannot
use git for my work.
Morgan Christiansson wrote:
> Hi, i'm trying to "git svn fetch" my repository from a local file:///
> repo and i'm running into this problem:
>
> $ git svn init -t tags -b branches -T trunk file:///path/to/svn/repo
> $ git svn fetch
> branches/rails/rails/vendor/plugins/acts_as_xapian/.git/refs/heads/master
> was not found in commit a643e882c557593f36bb9fd0966490010b9dba61 (r10576)
>
>
> I found another report that seems to describe the same error:
> http://marc.info/?l=git&m=121537767308135&w=2
> Investigating the the history it's committed in r10577 and it's looking
> for it in r10576, so it seems to be off by one revision number. Exactly
> like the other report.
> I've tried the latest git version of git-svn.perl and the problem is not
> fixed there.
>
>
> $ svn log file:///path/to/repo -r10576:10577 -v
> ------------------------------------------------------------------------
> r10576 | morgan | 2008-11-28 14:35:53 +0000 (Fri, 28 Nov 2008) | 3 lines
> Changed paths:
> A /branches/rails/rails/app/controllers/browse_sheetmusic_controller.rb
> M /branches/rails/rails/app/controllers/scores_controller.rb
> M /branches/rails/rails/app/models/composer.rb
> M /branches/rails/rails/app/models/score.rb
> M /branches/rails/rails/config/routes.rb
>
> Commit message.
>
> ------------------------------------------------------------------------
> r10577 | morgan | 2008-11-28 18:31:00 +0000 (Fri, 28 Nov 2008) | 3 lines
> Changed paths:
> A /branches/rails/rails/vendor/plugins/acts_as_xapian/.git/FETCH_HEAD
> M /branches/rails/rails/vendor/plugins/acts_as_xapian/.git/config
> M /branches/rails/rails/vendor/plugins/acts_as_xapian/.git/index
> M /branches/rails/rails/vendor/plugins/acts_as_xapian/.git/logs/HEAD
> M
> /branches/rails/rails/vendor/plugins/acts_as_xapian/.git/logs/refs/heads/master
>
> # <-- THIS FILE
> M
> /branches/rails/rails/vendor/plugins/acts_as_xapian/.git/logs/refs/remotes/origin/HEAD
>
> M
> /branches/rails/rails/vendor/plugins/acts_as_xapian/.git/logs/refs/remotes/origin/master
>
> A
> /branches/rails/rails/vendor/plugins/acts_as_xapian/.git/objects/pack/pack-41ebdff27c581340ac7a71850e2e3a7d1cfea138.idx
>
> A
> /branches/rails/rails/vendor/plugins/acts_as_xapian/.git/objects/pack/pack-41ebdff27c581340ac7a71850e2e3a7d1cfea138.pack
>
> M
> /branches/rails/rails/vendor/plugins/acts_as_xapian/.git/refs/heads/master
>
> M
> /branches/rails/rails/vendor/plugins/acts_as_xapian/.git/refs/remotes/origin/master
>
> A /branches/rails/rails/vendor/plugins/acts_as_xapian/README.textile
> M
> /branches/rails/rails/vendor/plugins/acts_as_xapian/lib/acts_as_xapian.rb
>
> Switched repo to git://github.com/Overbryd/acts_as_xapian.git
>
> ------------------------------------------------------------------------
>
>
>
>
> I did some digging in the perl script and managed to generate this stack
> trace, it shows that gs_do_update is called with $rev_a=10576 and
> $rev_b=10577, the file is in $rev_b but it complains it's not found in
> $rev_a.
>
> SVN::Git::Fetcher::open_file('SVN::Git::Fetcher=HASH(0x25faf38)',
> 'branches/rails/rails/vendor/plugins/acts_as_xapian/.git/refs/heads/master',
>
> 'HASH(0x25fdb00)', 10576, '_p_apr_pool_t=SCALAR(0x24f8978)') called at
> /usr/lib/perl5/SVN/Ra.pm line 623
> SVN::Ra::Reporter::AUTOLOAD('SVN::Ra::Reporter=ARRAY(0x24f8948)',
> 'SVN::Pool=REF(0x24f8528)') called at ../git-svn.perl line 4087
> Git::SVN::Ra::gs_do_update('Git::SVN::Ra=HASH(0x24beac8)', 10576, 10577,
> 'Git::SVN=HASH(0x24f7d18)', 'SVN::Git::Fetcher=HASH(0x25faf38)') called
> at ../git-svn.perl line 2481
> Git::SVN::do_fetch('Git::SVN=HASH(0x24f7d18)', 'HASH(0x24c01f0)', 10577)
> called at ../git-svn.perl line 4227
> Git::SVN::Ra::gs_fetch_loop_common('Git::SVN::Ra=HASH(0x24beac8)',
> 10575, 10724, 'ARRAY(0x1da1c20)', 'ARRAY(0x1da1c50)') called at
> ../git-svn.perl line 1506
> Git::SVN::fetch_all('svn', 'HASH(0x21d6440)') called at ../git-svn.perl
> line 387
> main::cmd_fetch at ../git-svn.perl line 268
> eval {...} at ../git-svn.perl line 266
> branches/rails/rails/vendor/plugins/acts_as_xapian/.git/refs/heads/master
> was not found in commit a643e882c557593f36bb9fd0966490010b9dba61
> (r10576) at ../git-svn.perl line 3271.
>
>
> I'm not sure whether this is correct behavior or not and I'm not
> familiar with SVN::Ra::Reporter... so some help would be appreciated.
>
> Thanks,
> Morgan
>
> --
> 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
* Lightweight tag ?
From: Francis Moreau @ 2009-01-11 18:44 UTC (permalink / raw)
To: git
Hello,
I'm puzzling about the lightweight.
My problem is that I don't see their point !
They behave the same way like the annotated tags: when pushing to a
repo the lightweight tags are pushed as well, and pulling from a repo
with lightweight tags give the same results (all of this with the
--tags switch).
I would have thought that these kind of tags are local to a
repository but it doesn't look so.
So could anybody give me a useful use case for lightweight tags ?
And how can I create local tags ?
Thanks
--
Francis
^ permalink raw reply
* Re: [PATCH] Cleanup of unused symcache variable inside diff-lib.c
From: Johannes Schindelin @ 2009-01-11 18:45 UTC (permalink / raw)
To: Kjetil Barvik; +Cc: git, Junio C Hamano
In-Reply-To: <1231699002-5316-1-git-send-email-barvik@broadpark.no>
Hi,
On Sun, 11 Jan 2009, Kjetil Barvik wrote:
> ---
> :100644 100644 ae96c64... e6d1d2b... M diff-lib.c
I wonder what that line is all about, since ...
> diff-lib.c | 40 +++++++++++-----------------------------
> 1 files changed, 11 insertions(+), 29 deletions(-)
>
> diff --git a/diff-lib.c b/diff-lib.c
> index ae96c64ca209f4df9008198e8a04b160bed618c7..e6d1d2b34147a13aadb5019e0c8336ef5f56ee39 100644
... we have the information right there already.
Ciao,
Dscho
^ permalink raw reply
* Re: current git kernel has strange problems during bisect
From: Linus Torvalds @ 2009-01-11 19:13 UTC (permalink / raw)
To: Christian Borntraeger; +Cc: Johannes Schindelin, git, Linux Kernel Mailing List
In-Reply-To: <200901111620.03345.borntraeger@de.ibm.com>
On Sun, 11 Jan 2009, Christian Borntraeger wrote:
>
> I think we should really avoid merging subtrees to the linux kernel. It
> makes bisecting a real PITA. Furthermore, It is unlikely, but what if
> the problem is part of the 581 changesets from btrfs?
Umm, yes?
The thing is, btrfs was developed as an outside module. There are two
choices: import it with history, or import it without history. The history
is interesting, so importing _with_ it is a much nicer one. But that does
mean that btrfs introduces into the kernel tree the same behaviour we've
had in the git development tree for a long time - multiple root commits,
and "independent" branches that get merged.
It's actually very natural for git, and the btrfs tree actually was
re-done with "git filter-branch" to move all the history so that it is in
fs/btrfs, rather than moving around from the root like the _original_
development was done. So it's not technically a subtree merge, it's a
regular merge with just two different root commits - one for the original
base kernel development, one for the original btrfs kernel development.
For bisect, it's indeed somewhat annoying, and we could have perhaps done
some things a bit differently, but it's about the closest you can get to
"real history" without making the first btrfs merge-point a _total_
disaster.
For bisect purposes, if you know you're not chasing down a btrfs issue,
you can do
git bisect good 34353029534a08e41cfb8be647d734b9ce9ebff8
where that commit 34353029 is the last one which has _just_ the btrfs
files. The next commit is when it does "Merge Btrfs into fs/btrfs", and
that one has the whole kernel tree again.
Linus
^ permalink raw reply
* Re: [PATCH] Cleanup of unused symcache variable inside diff-lib.c
From: Kjetil Barvik @ 2009-01-11 19:32 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.0901111944360.3586@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Sun, 11 Jan 2009, Kjetil Barvik wrote:
>
>> ---
>> :100644 100644 ae96c64... e6d1d2b... M diff-lib.c
>
> I wonder what that line is all about, since ...
>
>> diff-lib.c | 40 +++++++++++-----------------------------
>> 1 files changed, 11 insertions(+), 29 deletions(-)
>>
>> diff --git a/diff-lib.c b/diff-lib.c
>> index ae96c64ca209f4df9008198e8a04b160bed618c7..e6d1d2b34147a13aadb5019e0c8336ef5f56ee39 100644
>
> ... we have the information right there already.
>
> Ciao,
> Dscho
hmmm, I tried the following commands
jetil@localhost ~/git/git $ git pull
Already up-to-date.
kjetil@localhost ~/git/git $ git checkout -q my_origin_maint && grep symcache *.c
diff-lib.c: char symcache[PATH_MAX];
diff-lib.c: symcache[0] = '\0';
diff-lib.c: char symcache[PATH_MAX];
diff-lib.c: unpack_cb.symcache[0] = '\0';
diff-lib.c: unpack_cb.symcache[0] = '\0';
kjetil@localhost ~/git/git $ git checkout -q my_origin_master && grep symcache *.c
diff-lib.c: char symcache[PATH_MAX];
diff-lib.c: symcache[0] = '\0';
diff-lib.c: char symcache[PATH_MAX];
diff-lib.c: unpack_cb.symcache[0] = '\0';
diff-lib.c: unpack_cb.symcache[0] = '\0';
kjetil@localhost ~/git/git $ git checkout -q my_origin_next && grep symcache *.c
diff-lib.c: char symcache[PATH_MAX];
diff-lib.c: symcache[0] = '\0';
diff-lib.c: char symcache[PATH_MAX];
diff-lib.c: unpack_cb.symcache[0] = '\0';
diff-lib.c: unpack_cb.symcache[0] = '\0';
kjetil@localhost ~/git/git $ git checkout -q my_origin_pu && grep symcache *.c
diff-lib.c: char symcache[PATH_MAX];
diff-lib.c: symcache[0] = '\0';
diff-lib.c: char symcache[PATH_MAX];
diff-lib.c: unpack_cb.symcache[0] = '\0';
diff-lib.c: unpack_cb.symcache[0] = '\0';
kjetil@localhost ~/git/git $ cd
kjetil@localhost ~ $ mkdir git2
kjetil@localhost ~ $ cd git2
kjetil@localhost ~/git2 $ git clone -q git://git.kernel.org/pub/scm/git/git.git
kjetil@localhost ~/git2 $ cd git/
kjetil@localhost ~/git2/git $ git show e6d1d2b34147a13aadb5019e0c8336ef5f56ee39
outputs =>
fatal: bad object e6d1d2b34147a13aadb5019e0c8336ef5f56ee39
kjetil@localhost ~/git2/git $ git show e6d1d2b
outputs =>
fatal: ambiguous argument 'e6d1d2b': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions
kjetil@localhost ~/git2/git $ git show -- e6d1d2b
outputs => (nothing)
Can you explain to a new git user? As far as I can tell, I do not see
that this patch is included in the public awailable git tree. Where
should the patch be? I can not see it... help!
-- kjetil
^ permalink raw reply
* Re: current git kernel has strange problems during bisect
From: Sam Ravnborg @ 2009-01-11 19:42 UTC (permalink / raw)
To: Linus Torvalds
Cc: Christian Borntraeger, Johannes Schindelin, git,
Linux Kernel Mailing List
In-Reply-To: <alpine.LFD.2.00.0901111113150.6528@localhost.localdomain>
>
> For bisect, it's indeed somewhat annoying, and we could have perhaps done
> some things a bit differently, but it's about the closest you can get to
> "real history" without making the first btrfs merge-point a _total_
> disaster.
>
> For bisect purposes, if you know you're not chasing down a btrfs issue,
> you can do
>
> git bisect good 34353029534a08e41cfb8be647d734b9ce9ebff8
>
> where that commit 34353029 is the last one which has _just_ the btrfs
> files. The next commit is when it does "Merge Btrfs into fs/btrfs", and
> that one has the whole kernel tree again.
The cost of moving this piece of history from one git tree to another
git tree is that we make it harder to debug the kernel for the advanced user
that knows how to do bisect.
It is not like this history would be lost - one just had to look
somewhere else to find it.
That may be a bad pain/benefit ratio - time will tell.
There should be a way to avoid such pain when bisecting without
having to mark a semi-random (for the average person) commit as good.
As in something that is present when the average bisect user pull the tree,
and not something the user has to do afterwards.
Sam
^ permalink raw reply
* Re: [PATCH] Cleanup of unused symcache variable inside diff-lib.c
From: Johannes Schindelin @ 2009-01-11 19:46 UTC (permalink / raw)
To: Kjetil Barvik; +Cc: git, Junio C Hamano
In-Reply-To: <86iqol8wql.fsf@broadpark.no>
Hi,
On Sun, 11 Jan 2009, Kjetil Barvik wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Sun, 11 Jan 2009, Kjetil Barvik wrote:
> >
> >> :100644 100644 ae96c64... e6d1d2b... M diff-lib.c
>
> [...]
>
> kjetil@localhost ~/git2 $ git clone -q git://git.kernel.org/pub/scm/git/git.git
> kjetil@localhost ~/git2 $ cd git/
> kjetil@localhost ~/git2/git $ git show e6d1d2b34147a13aadb5019e0c8336ef5f56ee39
> outputs =>
> fatal: bad object e6d1d2b34147a13aadb5019e0c8336ef5f56ee39
Your patch has not been applied yet. So no surprise there: your version
of diff-lib.c is not there. You'll have more luck with ae96c64, I
guess...
My question was more: why do you do additional work and put a git diff
--raw between the commit message and the diffstat when that information is
in the patch already?
Ciao,
Dscho
^ permalink raw reply
* Re: current git kernel has strange problems during bisect
From: Alexey Zaytsev @ 2009-01-11 19:47 UTC (permalink / raw)
To: Sam Ravnborg
Cc: Linus Torvalds, Christian Borntraeger, Johannes Schindelin, git,
Linux Kernel Mailing List
In-Reply-To: <20090111194258.GA4840@uranus.ravnborg.org>
On Sun, Jan 11, 2009 at 22:42, Sam Ravnborg <sam@ravnborg.org> wrote:
>>
>> For bisect, it's indeed somewhat annoying, and we could have perhaps done
>> some things a bit differently, but it's about the closest you can get to
>> "real history" without making the first btrfs merge-point a _total_
>> disaster.
>>
>> For bisect purposes, if you know you're not chasing down a btrfs issue,
>> you can do
>>
>> git bisect good 34353029534a08e41cfb8be647d734b9ce9ebff8
>>
>> where that commit 34353029 is the last one which has _just_ the btrfs
>> files. The next commit is when it does "Merge Btrfs into fs/btrfs", and
>> that one has the whole kernel tree again.
>
> The cost of moving this piece of history from one git tree to another
> git tree is that we make it harder to debug the kernel for the advanced user
> that knows how to do bisect.
And wasn't is trivial to avoid? Just exporting the commits as
patches and importing them into the kernel tree would preserve
the history, and not break bisection.
^ permalink raw reply
* Re: [PATCH v3 1/4] word diff: comments, preparations for regex customization
From: Johannes Schindelin @ 2009-01-11 19:49 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Junio C Hamano, Teemu Likonen
In-Reply-To: <4aea85caafd38a058145c5769fe8a30ffdbd4d13.1231669012.git.trast@student.ethz.ch>
Hi,
On Sun, 11 Jan 2009, Thomas Rast wrote:
> +/* unused right now */
> +enum diff_word_boundaries {
> + DIFF_WORD_UNDEF,
> + DIFF_WORD_BODY,
> + DIFF_WORD_END,
> + DIFF_WORD_SPACE,
> + DIFF_WORD_SKIP
> +};
> +
Just to illustrate why I reacted so harshly to this patch series: this
change is utterly useless.
You do not use the word boundaries at all throughout the complete patch.
This would have been the only way you could have possibly illustrated how
the enum is to be used at all, given that you did not document what the
enum should do eventually.
With such a patch that leaves me as clueless as to the way you want to fix
the issues as before, I regret having spent the time to look at it at all.
What you _should_ have done:
- _not_ introduce the regex. That is not what the first patch should be
about.
- _use_ the enum for the existing functionality.
- _explain_ what the different values of the enum are about.
- _say_ what the enum pointer points at (is it a single value? an array?
if it is an array, is it per letter? per word?)
If you are honest, you'll admit that this patch would leave you puzzled
_yourself_, 6 months from now.
FWIW I think I have a better patch series, to be sent in a few minutes.
Ciao,
Dscho
^ permalink raw reply
* [PATCH 0/4] refactor the --color-words to make it more hackable
From: Johannes Schindelin @ 2009-01-11 19:58 UTC (permalink / raw)
To: git, Thomas Rast
So the total change is pretty large, I have to admit.
But at least _I_ think it is easy to follow, and it actually makes the code
more readable/hackable. Correct me if I'm wrong.
The basic idea is to decouple the original text from the text that is
passed to libxdiff to find the word differences.
To that end, the words of the pre and post texts are put into two lists that
are fed to libxdiff. While the words are extracted, an array is created which
contains pointers back to the word boundaries in the original text.
To make the transition as easy to understand as possible, the code is first
refactored without actually changing what makes a word boundary.
Johannes Schindelin (4):
Add color_fwrite(), a function coloring each line individually
color-words: refactor word splitting and use ALLOC_GROW()
color-words: refactor to allow for 0-character word boundaries
color-words: take an optional regular expression describing words
color.c | 24 ++++++++
color.h | 1 +
diff.c | 185 +++++++++++++++++++++++++++++++++++++++------------------------
diff.h | 1 +
4 files changed, 141 insertions(+), 70 deletions(-)
^ permalink raw reply
* [PATCH 1/4] Add color_fwrite(), a function coloring each line individually
From: Johannes Schindelin @ 2009-01-11 19:59 UTC (permalink / raw)
To: git, Thomas Rast
In-Reply-To: <alpine.DEB.1.00.0901112057300.3586@pacific.mpi-cbg.de>
We have to set the color before every line and reset it before every
newline. Add a function color_fwrite() which does that for us.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
color.c | 24 ++++++++++++++++++++++++
color.h | 1 +
2 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/color.c b/color.c
index fc0b72a..bff24ac 100644
--- a/color.c
+++ b/color.c
@@ -191,3 +191,27 @@ int color_fprintf_ln(FILE *fp, const char *color, const char *fmt, ...)
va_end(args);
return r;
}
+
+/*
+ * This function splits the buffer by newlines and colors the lines individually.
+ */
+void color_fwrite(FILE *f, const char *color, size_t count, const char *buf)
+{
+ if (!*color) {
+ fwrite(buf, count, 1, f);
+ return;
+ }
+ while (count) {
+ char *p = memchr(buf, '\n', count);
+ fputs(color, f);
+ fwrite(buf, p ? p - buf : count, 1, f);
+ fputs(COLOR_RESET, f);
+ if (!p)
+ return;
+ fputc('\n', f);
+ count -= p + 1 - buf;
+ buf = p + 1;
+ }
+}
+
+
diff --git a/color.h b/color.h
index 6cf5c88..9fb58f5 100644
--- a/color.h
+++ b/color.h
@@ -19,5 +19,6 @@ int git_config_colorbool(const char *var, const char *value, int stdout_is_tty);
void color_parse(const char *var, const char *value, char *dst);
int color_fprintf(FILE *fp, const char *color, const char *fmt, ...);
int color_fprintf_ln(FILE *fp, const char *color, const char *fmt, ...);
+void color_fwrite(FILE *f, const char *color, size_t count, const char *buf);
#endif /* COLOR_H */
--
1.6.1.186.g48f3bc4
^ permalink raw reply related
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