* Re: Merge priority
From: Alex Riesen @ 2009-11-26 15:42 UTC (permalink / raw)
To: Howard Miller; +Cc: git
In-Reply-To: <26ae428a0911260444j45437a92r47d7f2e8b292829e@mail.gmail.com>
On Thu, Nov 26, 2009 at 13:44, Howard Miller <howard@e-learndesign.co.uk> wrote:
> I now want to update all my customer branches with the latest fixes
> and patches. Naively, I would just check out each branch and merge the
> stable branch - job done. However, is it sensible to ask if there is a
> way to say that the stable branch is more important if there are
> conflicts.
No, all branches are equal. Besides, are you sure it is safe to just take
your stable version of the code in a conflict? Maybe the stable code uses
something a customer branch renamed or removed?
You can take a look at rerere, though. It should help resolving repeating
conflicts by recording a resolution of your choice.
^ permalink raw reply
* Re: [RFC/PATCH 2/2] status -s: obey color.status
From: Johannes Sixt @ 2009-11-26 15:36 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git, Junio C Hamano
In-Reply-To: <26d0a2022638ad7b75268ca291b8d02a22f1f66c.1259248243.git.git@drmicha.warpmail.net>
Michael J Gruber schrieb:
> * Is there any policy regarding use of putchar/puts vs. printf?
If the printed string contains color escapes that should be obeyed, you
can use only fputs, printf, and fprintf. You should not use puts or putchar.
> * Even if I were to write tests for status -s: How do I test colors?
See t4034-diff-words.sh.
-- Hannes
^ permalink raw reply
* Re: [egit-dev] Re: jgit problems for file paths with non-ASCII characters
From: Thomas Singer @ 2009-11-26 15:31 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Shawn O. Pearce, Marc Strapetz, git
In-Reply-To: <alpine.DEB.1.00.0911261546350.7500@intel-tinevez-2-302>
> You mean we should do the same thing as Apple with HFS? Are you serious?
Yes, I'm serious. IMHO there should be a defined clear encoding used for
files names in the repository. Otherwise you don't know what you can expect
by reading it - it could mean anything. File names are in fact strings which
are based on characters. To convert characters to bytes (or visa versa) you
need to know the encoding.
--
Best regards,
Thomas Singer
=============
syntevo GmbH
http://www.syntevo.com
http://blog.syntevo.com
Johannes Schindelin wrote:
> Hi,
>
> On Thu, 26 Nov 2009, Thomas Singer wrote:
>
>> [someone said, Thomas did not say who]
>>
>>> But as you said, this still doesn't make the Apple normal form any
>>> easier. Though if we know we are on such a strange filesystem we
>>> might be able to assume the paths in the repository are equally
>>> damaged. Or not.
>> Well, if the git-core folks could standardize on, e.g., composed UTF-8
>> (rather then just UTF-8), for storing file names in the repository, then
>> everything should be clear, isn't it?
>
> You mean we should do the same thing as Apple with HFS? Are you serious?
>
> Ciao,
> Dscho
^ permalink raw reply
* [RFC/PATCH 2/2] status -s: obey color.status
From: Michael J Gruber @ 2009-11-26 15:24 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <cover.1259248243.git.git@drmicha.warpmail.net>
Make the short version of status obey the color.status boolean. We color
the status letters only, because they carry the state information and are
potentially colored differently, such as for a file with staged changes
as well as changes in the worktree against the index.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
This is RFC for several reasons:
* Should I rename wt-status.c's color() into something more unique when
I export it?
* Is there any policy regarding use of putchar/puts vs. printf?
* The way it is done now I "color" a space, otherwise one would need to
break down the print statements even more. Since we always color the
foreground only it is no problem, is it?
* Even if I were to write tests for status -s: How do I test colors?
builtin-commit.c | 20 +++++++++++++++-----
wt-status.c | 2 +-
wt-status.h | 1 +
3 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index c103beb..c38fc96 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -999,7 +999,7 @@ static void short_unmerged(int null_termination, struct string_list_item *it,
case 6: how = "AA"; break; /* both added */
case 7: how = "UU"; break; /* both modified */
}
- printf("%s ", how);
+ color_fprintf(s->fp, color(WT_STATUS_UNMERGED, s), "%s ", how);
if (null_termination) {
fprintf(stdout, "%s%c", it->string, 0);
} else {
@@ -1016,9 +1016,14 @@ static void short_status(int null_termination, struct string_list_item *it,
{
struct wt_status_change_data *d = it->util;
- printf("%c%c ",
- !d->index_status ? ' ' : d->index_status,
- !d->worktree_status ? ' ' : d->worktree_status);
+ if (d->index_status)
+ color_fprintf(s->fp, color(WT_STATUS_UPDATED, s), "%c", d->index_status);
+ else
+ putchar(' ');
+ if (d->worktree_status)
+ color_fprintf(s->fp, color(WT_STATUS_CHANGED, s), "%c ", d->worktree_status);
+ else
+ printf(" ");
if (null_termination) {
fprintf(stdout, "%s%c", it->string, 0);
if (d->head_path)
@@ -1046,7 +1051,8 @@ static void short_untracked(int null_termination, struct string_list_item *it,
struct strbuf onebuf = STRBUF_INIT;
const char *one;
one = quote_path(it->string, -1, &onebuf, s->prefix);
- printf("?? %s\n", one);
+ color_fprintf(s->fp, color(WT_STATUS_UNTRACKED, s), "?? ");
+ puts(one);
strbuf_release(&onebuf);
}
}
@@ -1115,6 +1121,10 @@ int cmd_status(int argc, const char **argv, const char *prefix)
case STATUS_FORMAT_SHORT:
if (s.relative_paths)
s.prefix = prefix;
+ if (s.use_color == -1)
+ s.use_color = git_use_color_default;
+ if (diff_use_color_default == -1)
+ diff_use_color_default = git_use_color_default;
short_print(&s, null_termination);
break;
case STATUS_FORMAT_PORCELAIN:
diff --git a/wt-status.c b/wt-status.c
index 3c2f580..c779b7c 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -19,7 +19,7 @@ static char default_wt_status_colors[][COLOR_MAXLEN] = {
GIT_COLOR_RED, /* WT_STATUS_UNMERGED */
};
-static const char *color(int slot, struct wt_status *s)
+const char *color(int slot, struct wt_status *s)
{
return s->use_color > 0 ? s->color_palette[slot] : "";
}
diff --git a/wt-status.h b/wt-status.h
index 09fd9f1..22b15b0 100644
--- a/wt-status.h
+++ b/wt-status.h
@@ -55,5 +55,6 @@ struct wt_status {
void wt_status_prepare(struct wt_status *s);
void wt_status_print(struct wt_status *s);
void wt_status_collect(struct wt_status *s);
+const char *color(int slot, struct wt_status *s);
#endif /* STATUS_H */
--
1.6.6.rc0.274.g71380
^ permalink raw reply related
* [RFC/PATCH 1/2] status -s: respect the status.relativePaths option
From: Michael J Gruber @ 2009-11-26 15:24 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <cover.1259248243.git.git@drmicha.warpmail.net>
so that 'status' and 'status -s' in a subdir produce the same file
names.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
Anything else would be highly surprising. Note that the porcelain case
is unchanged, of course.
builtin-commit.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index 7f888fe..c103beb 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -1113,6 +1113,8 @@ int cmd_status(int argc, const char **argv, const char *prefix)
switch (status_format) {
case STATUS_FORMAT_SHORT:
+ if (s.relative_paths)
+ s.prefix = prefix;
short_print(&s, null_termination);
break;
case STATUS_FORMAT_PORCELAIN:
--
1.6.6.rc0.274.g71380
^ permalink raw reply related
* [RFC/PATCH 0/2] status -s: Use the same config as status
From: Michael J Gruber @ 2009-11-26 15:24 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
This mini series is an RFC for bringing the short version of status in line
with the longer one. They already both obey status.showUntrackedFiles.
Currently, status -s does not obey status.relativePaths nor
color.status.
I think status should follow the priniciple of least surprise here in
the sense that -s should not change other aspects of the output
(although it is very different internally).
I think we don't have any tests for status -s yet, which is one reason
why this is an RFC: I don't expect to get through with it, like the
introducer of status -s did ;) Another reason is mentioned in 2/2.
Michael J Gruber (2):
status -s: respect the status.relativePaths option
status -s: obey color.status
builtin-commit.c | 22 +++++++++++++++++-----
wt-status.c | 2 +-
wt-status.h | 1 +
3 files changed, 19 insertions(+), 6 deletions(-)
^ permalink raw reply
* Re: [egit-dev] Re: jgit problems for file paths with non-ASCII characters
From: Johannes Schindelin @ 2009-11-26 14:47 UTC (permalink / raw)
To: Thomas Singer
Cc: Shawn O. Pearce, EGit developer discussion, Marc Strapetz, git
In-Reply-To: <4B0E7DF5.9040007@syntevo.com>
Hi,
On Thu, 26 Nov 2009, Thomas Singer wrote:
> [someone said, Thomas did not say who]
>
> > But as you said, this still doesn't make the Apple normal form any
> > easier. Though if we know we are on such a strange filesystem we
> > might be able to assume the paths in the repository are equally
> > damaged. Or not.
>
> Well, if the git-core folks could standardize on, e.g., composed UTF-8
> (rather then just UTF-8), for storing file names in the repository, then
> everything should be clear, isn't it?
You mean we should do the same thing as Apple with HFS? Are you serious?
Ciao,
Dscho
^ permalink raw reply
* Re: [egit] Git repository with multiple eclipse projects ?
From: Yann Dirson @ 2009-11-26 14:30 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20091126004817.GL11919@spearce.org>
On Wed, Nov 25, 2009 at 04:48:17PM -0800, Shawn O. Pearce wrote:
> > When importing a git repo into eclipse, we get a list of projects to
> > import, but that list is empty. What is expected by egit to get this
> > list filled ?
>
> There should be .project files in the repository. I think we scan
> the entire checkout tree for .project files, but maybe we are doing
> something stupid and only looking at the top level directory of
> the checkout.
Right, we could make it work - the devs just did not have the habbit
of commiting .project files.
> > It also does not look like it would be possible to use the "share"
> > functionnality to setup such a repository from multiple projects (or
> > from a project set), right ?
>
> Nope, I don't think this is supported right now. You need to
> initialize the git repository by hand in the higher level directory
> that holds the projects.
Yes, we did that by git-add'ing the initial projects manually and
pushing them, and we can now "import" that.
That makes me wonder if it should work to add a new project afterwards
from within Eclipse. If we create a new project under the git tree,
and try to use "share", then we get presented a folded list containing
the project we want to add, which when unfolded reveals "..\.git"
(yes, this test done on windows) as repository, which is promising.
But then the field below near the "Create" button (the one with
"\.git" text on the right) gets polulated with the full project path
when we click on the project in the list, and we could not unlock the
"next" or "finish" button. Are we just trying things the way they
should work but hit functionnality that is just not finished, or are
we completely off-track ?
Thanks much,
--
Yann
^ permalink raw reply
* Re: [egit-dev] Re: jgit problems for file paths with non-ASCII characters
From: Marc Strapetz @ 2009-11-26 14:25 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: EGit developer discussion, git, robin.rosenberg
In-Reply-To: <20091126005423.GM11919@spearce.org>
> We should try to work harder with the git-core folks to get character
> set encoding for file names worked out. We might be able to use a
> configuration setting in the repository to tell us what the proper
> encoding should be, and if not set, assume UTF-8.
I agree that this should be the ultimate goal, though the default should
better be "system encoding" for compatibility with current git
repositories and instead have newer git versions always set encoding to
UTF-8. Thus, for our jgit clone I've introduced a system property to
configure Constants.PATH_ENCODING set to system encoding. It's used by
PathFilter and this resolves my original problem.
I have tried to switch more usages from Constants.CHARACTER_ENCODING to
Constants.PATH_ENCODING, but ended up in confusion due to my lack of
understanding: primarily because I couldn't tell anymore whether encoded
strings were file names or not. Does it make sense to explicitly
distinguish encoding usages in that way? We could try to contribute here
(and hopefully cause less review effort to jgit developers than the
changes itself are worth ;-)
--
Best regards,
Marc Strapetz
=============
syntevo GmbH
http://www.syntevo.com
http://blog.syntevo.com
Shawn O. Pearce wrote:
> Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
>> onsdag 25 november 2009 14:47:25 skrev Marc Strapetz:
>>> I have noticed that jgit converts file paths to UTF-8 when querying the
>>> repository.
> ...
>>> Is this a bug or a misconfiguration of my repository? I'm using jgit
>>> (commit e16af839e8a0cc01c52d3648d2d28e4cb915f80f) on Windows.
>> A bug.
>>
>> The problem here is that we need to allow multiple encodings since there
>> is no reliable encoding specified anywhere.
>
> This is a design fault of both Linux and git. git gets a byte
> sequence from readdir and stores that as-is into the repository.
> We have no way of knowing what that encoding is. So now everyone
> touching a Git repository is screwed.
>
>> The approach I advocate is
>> the one we use for handling encoding in general. I.e. if it looks like UTF-8,
>> treat it like that else fallback. This is expensive however
>
> We should try to work harder with the git-core folks to get character
> set encoding for file names worked out. We might be able to use a
> configuration setting in the repository to tell us what the proper
> encoding should be, and if not set, assume UTF-8.
>
>> and then we have
>> all the other issues with case insensitive name and the funny property that
>> unicode has when it allows characters to be encoding using multiple sequences
>> of code points as empoloyed by Apple.
>
> But as you said, this still doesn't make the Apple normal form
> any easier. Though if we know we are on such a strange filesystem
> we might be able to assume the paths in the repository are equally
> damaged. Or not.
>
^ permalink raw reply
* Re: [PATCH (resend)] Let core.excludesfile default to ~/.gitexcludes.
From: Michael J Gruber @ 2009-11-26 13:39 UTC (permalink / raw)
To: Bert Wesarg; +Cc: Matthieu Moy, git, gitster
In-Reply-To: <36ca99e90911260501q571929e5l114cb0af9f374a98@mail.gmail.com>
Bert Wesarg venit, vidit, dixit 26.11.2009 14:01:
> On Thu, Nov 26, 2009 at 13:00, Michael J Gruber
> <git@drmicha.warpmail.net> wrote:
>> Matthieu Moy venit, vidit, dixit 26.11.2009 11:35:
>>> Most users will set it to ~/.gitsomething. ~/.gitignore would conflict
>>> with per-directory ignore file if ~/ is managed by Git, so ~/.gitexcludes
>>> is a sane default.
>>
>> I'm sorry to jump in so late, and this may sound like bike-shedding, but
>> right now we have
>>
>> .git/info/exclude
>> .gitignore
>>
>> and this would add
>>
>> ~/.gitexcludes
>>
>> That is, three terms, or two, where one comes in two variations
>> (exclude/exludes). I always wondered why we have two.
>>
>> The reason for .gitignore is most probably the similarity to
>> .${othervcs}ignore, and that is a valid reason.
>>
>> I know we have ~/.gitconfig for the global version of .git/config, and
>> maybe that was just no good idea either. But I don't even dare
>> suggesting to rename it ~/.gitglobalconfig.
>>
>> So, in line at least with our term "global" (per user) config, I would
>> suggest to use "~/.gitglobalignore" for the global ignore file. Maybe,
>> eventually, we'll manage to rename .git/info/excludes to .git/info/ignore.
>>
>> On a somewhat larger scale, a good alternative strategy would be to have
>> a directory "~/.gitglobal/" in which Git would look for
>> ~/.gitglobal/config and
>> ~/.gitglobal/info/ignore or
>> ~/.gitglobal/ignore
>>
>> i.e. mirroring the repo structure or at least bundling everything in a
>> single dir, which would also be a good place for a global svnauthors
>> file and such, and for other global configuration files we don't think
>> of right now.
> I would vote for that too. Its more future-proof than a single new
> file. Also I would suggest to name this dir ~/.gitrc/.
Now, that is bike shedding ;)
It seems to me that all ~/.*rc that I have are config files (.bashrc,
.xinitrc...), and all condif subdirs ~/.* are named by the
program/subsystem (.qt, .kde, .gnupg), which we cannot do any more, and
which is why I suggested .gitglobal. But I'd be fine with .gitrc.
> On the other
> hand the --global option to git config specifies the .gitconfig in
> your HOME.
That would have to change (ouch, ducking). Transition plan would be:
~/.gitconfig, ~/.gitrc/config::
User-specific configuration file. Also called "global"
configuration file. Git looks in these locations in the
specified order and uses the first one it finds.
$(prefix)/etc/gitconfig, $(prefix)/etc/gitrc/config::
System-wide configuration file. Git looks in these locations
in the specified order and uses the first one it finds.
This would mean no surprises for users with existing config, one could
teach the new preferred locations exclusively, and at some future point
one could phase out the old paths.
Michael
^ permalink raw reply
* Re: [PATCH (resend)] Let core.excludesfile default to ~/.gitexcludes.
From: Michael J Gruber @ 2009-11-26 13:27 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: git
In-Reply-To: <helthi$8k5$1@ger.gmane.org>
Paolo Bonzini venit, vidit, dixit 26.11.2009 13:49:
> On 11/26/2009 01:00 PM, Michael J Gruber wrote:
>> I'm sorry to jump in so late, and this may sound like bike-shedding, but
>> right now we have
>>
>> .git/info/exclude
>> .gitignore
>>
>> and this would add
>>
>> ~/.gitexcludes
>>
>> That is, three terms, or two, where one comes in two variations
>> (exclude/exludes). I always wondered why we have two.
>
> Would you be fine with ~/.gitexclude?
Not really. You see, a user tracking his $HOME will have a ~/.gitignore
and a ~/.gitexclude then. I think we should distinguish local and global
"config" files more systematically. Which is why I suggested the subdir,
or having global in the name.
Michael
^ permalink raw reply
* Re: [egit-dev] Re: jgit problems for file paths with non-ASCII characters
From: Thomas Singer @ 2009-11-26 13:09 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: EGit developer discussion, Marc Strapetz, git
In-Reply-To: <20091126005423.GM11919@spearce.org>
> But as you said, this still doesn't make the Apple normal form
> any easier. Though if we know we are on such a strange filesystem
> we might be able to assume the paths in the repository are equally
> damaged. Or not.
Well, if the git-core folks could standardize on, e.g., composed UTF-8
(rather then just UTF-8), for storing file names in the repository, then
everything should be clear, isn't it?
--
Best regards,
Thomas Singer
=============
syntevo GmbH
http://www.syntevo.com
http://blog.syntevo.com
Shawn O. Pearce wrote:
> Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
>> onsdag 25 november 2009 14:47:25 skrev Marc Strapetz:
>>> I have noticed that jgit converts file paths to UTF-8 when querying the
>>> repository.
> ...
>>> Is this a bug or a misconfiguration of my repository? I'm using jgit
>>> (commit e16af839e8a0cc01c52d3648d2d28e4cb915f80f) on Windows.
>> A bug.
>>
>> The problem here is that we need to allow multiple encodings since there
>> is no reliable encoding specified anywhere.
>
> This is a design fault of both Linux and git. git gets a byte
> sequence from readdir and stores that as-is into the repository.
> We have no way of knowing what that encoding is. So now everyone
> touching a Git repository is screwed.
>
>> The approach I advocate is
>> the one we use for handling encoding in general. I.e. if it looks like UTF-8,
>> treat it like that else fallback. This is expensive however
>
> We should try to work harder with the git-core folks to get character
> set encoding for file names worked out. We might be able to use a
> configuration setting in the repository to tell us what the proper
> encoding should be, and if not set, assume UTF-8.
>
>> and then we have
>> all the other issues with case insensitive name and the funny property that
>> unicode has when it allows characters to be encoding using multiple sequences
>> of code points as empoloyed by Apple.
>
> But as you said, this still doesn't make the Apple normal form
> any easier. Though if we know we are on such a strange filesystem
> we might be able to assume the paths in the repository are equally
> damaged. Or not.
>
^ permalink raw reply
* Re: [PATCH (resend)] Let core.excludesfile default to ~/.gitexcludes.
From: Bert Wesarg @ 2009-11-26 13:01 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Matthieu Moy, git, gitster
In-Reply-To: <4B0E6DC9.3070105@drmicha.warpmail.net>
On Thu, Nov 26, 2009 at 13:00, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> Matthieu Moy venit, vidit, dixit 26.11.2009 11:35:
>> Most users will set it to ~/.gitsomething. ~/.gitignore would conflict
>> with per-directory ignore file if ~/ is managed by Git, so ~/.gitexcludes
>> is a sane default.
>
> I'm sorry to jump in so late, and this may sound like bike-shedding, but
> right now we have
>
> .git/info/exclude
> .gitignore
>
> and this would add
>
> ~/.gitexcludes
>
> That is, three terms, or two, where one comes in two variations
> (exclude/exludes). I always wondered why we have two.
>
> The reason for .gitignore is most probably the similarity to
> .${othervcs}ignore, and that is a valid reason.
>
> I know we have ~/.gitconfig for the global version of .git/config, and
> maybe that was just no good idea either. But I don't even dare
> suggesting to rename it ~/.gitglobalconfig.
>
> So, in line at least with our term "global" (per user) config, I would
> suggest to use "~/.gitglobalignore" for the global ignore file. Maybe,
> eventually, we'll manage to rename .git/info/excludes to .git/info/ignore.
>
> On a somewhat larger scale, a good alternative strategy would be to have
> a directory "~/.gitglobal/" in which Git would look for
> ~/.gitglobal/config and
> ~/.gitglobal/info/ignore or
> ~/.gitglobal/ignore
>
> i.e. mirroring the repo structure or at least bundling everything in a
> single dir, which would also be a good place for a global svnauthors
> file and such, and for other global configuration files we don't think
> of right now.
I would vote for that too. Its more future-proof than a single new
file. Also I would suggest to name this dir ~/.gitrc/. On the other
hand the --global option to git config specifies the .gitconfig in
your HOME.
Bert
>
> Michael
^ permalink raw reply
* Re: [PATCH (resend)] Let core.excludesfile default to ~/.gitexcludes.
From: Paolo Bonzini @ 2009-11-26 12:49 UTC (permalink / raw)
To: git
In-Reply-To: <4B0E6DC9.3070105@drmicha.warpmail.net>
On 11/26/2009 01:00 PM, Michael J Gruber wrote:
> I'm sorry to jump in so late, and this may sound like bike-shedding, but
> right now we have
>
> .git/info/exclude
> .gitignore
>
> and this would add
>
> ~/.gitexcludes
>
> That is, three terms, or two, where one comes in two variations
> (exclude/exludes). I always wondered why we have two.
Would you be fine with ~/.gitexclude?
Paolo
^ permalink raw reply
* Re: Working on merged branches whilst seeing current master
From: Tim Mazid @ 2009-11-26 12:45 UTC (permalink / raw)
To: git
In-Reply-To: <1258044562803-3994102.post@n2.nabble.com>
rhlee wrote:
>
>
> Tim Mazid wrote:
>>
>> Actually, there's no reason you couldn't just 'git reset HEAD^' once you
>> realise that the branch isn't ready. If you want to see the changes from
>> master, you could just merge that into your branch. If you just want to
>> see the content in master, you could use gitk or gitg, which allows you
>> to view files at any commit.
>>
>> Personally, I merge master into my branches, test and check, and fix,
>> then merge the branch into master. This sometimes results in a
>> fast-forward, if you haven't made changes to master. If you don't like
>> that, you can always use the --no-ff option, though.
>>
>
> I don't think 'git reset HEAD^' would work in my case as that only goes
> back one commit. I may have made many other changes on the master branch
> that I want to keep.
>
> By merging from master into your branch, like you said, you get a nice
> graph view that shows what you've brought into your branch from master
> since you last left off. But doesn't this goes against the idea that
> branches should be independent, by bringing in changes from master?
>
Yup, you only need to 'git reset HEAD^' on the master branch to undo the
merge. Isn't that what you wanted?
And yeah, I suppose it kind of does. But once again, you can 'git reset
HEAD^'. And since you're merging master INTO the branches, you are keeping
the branches independent, anyway.
--
View this message in context: http://n2.nabble.com/Working-on-merged-branches-whilst-seeing-current-master-tp3987667p4070977.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Merge priority
From: Howard Miller @ 2009-11-26 12:44 UTC (permalink / raw)
To: git
I'm not sure this is even a sensible question....
I have a whole bunch of customer branches with all manner of local
tweaks and modifications. I also have a stable branch with all my
security patches and bug fixes. They do share common ancestry.
I now want to update all my customer branches with the latest fixes
and patches. Naively, I would just check out each branch and merge the
stable branch - job done. However, is it sensible to ask if there is a
way to say that the stable branch is more important if there are
conflicts. Or should I be using rebase instead (which I still don't
really understand). I'm trying to reduce my workload as there are
loads of branches to do.
Cheers :-)
^ permalink raw reply
* [StGit] push/pull stacked patches
From: Kurt Harriman @ 2009-11-26 12:17 UTC (permalink / raw)
To: git
Suppose two developers are collaborating on a series of patches.
What is the best way to synchronize their repositories, including
the StGit state?
Even if both repositories are StGit-enabled, the patch metadata
and unapplied patches don't seem to be transferred by push/pull.
Applied patches are transferred as ordinary commits, losing
their patch names and their place in the patch stack.
It seems that a remote branch cannot have a patch stack.
Instead of using push/pull, a patch series can be transferred
using stg export/import, but this is error-prone, requiring
extra steps, and changes the commit timestamp and SHA1.
Stg export/import are good for distributing the final version
of a patch series; but ungitly for back-and-forth collaboration.
Is there a better way?
^ permalink raw reply
* Re: [PATCH] Give the hunk comment its own color
From: Bert Wesarg @ 2009-11-26 12:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7vaayjebu5.fsf@alter.siamese.dyndns.org>
Junio,
may I kindly remind you of this patch. If it is only the nen-existing
consensus of the default color, than please use the die.
Kind regards,
Bert Wesarg
^ permalink raw reply
* Re: [PATCH (resend)] Let core.excludesfile default to ~/.gitexcludes.
From: Michael J Gruber @ 2009-11-26 12:00 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git, gitster
In-Reply-To: <1259231726-5218-1-git-send-email-Matthieu.Moy@imag.fr>
Matthieu Moy venit, vidit, dixit 26.11.2009 11:35:
> Most users will set it to ~/.gitsomething. ~/.gitignore would conflict
> with per-directory ignore file if ~/ is managed by Git, so ~/.gitexcludes
> is a sane default.
I'm sorry to jump in so late, and this may sound like bike-shedding, but
right now we have
.git/info/exclude
.gitignore
and this would add
~/.gitexcludes
That is, three terms, or two, where one comes in two variations
(exclude/exludes). I always wondered why we have two.
The reason for .gitignore is most probably the similarity to
.${othervcs}ignore, and that is a valid reason.
I know we have ~/.gitconfig for the global version of .git/config, and
maybe that was just no good idea either. But I don't even dare
suggesting to rename it ~/.gitglobalconfig.
So, in line at least with our term "global" (per user) config, I would
suggest to use "~/.gitglobalignore" for the global ignore file. Maybe,
eventually, we'll manage to rename .git/info/excludes to .git/info/ignore.
On a somewhat larger scale, a good alternative strategy would be to have
a directory "~/.gitglobal/" in which Git would look for
~/.gitglobal/config and
~/.gitglobal/info/ignore or
~/.gitglobal/ignore
i.e. mirroring the repo structure or at least bundling everything in a
single dir, which would also be a good place for a global svnauthors
file and such, and for other global configuration files we don't think
of right now.
Michael
^ permalink raw reply
* Re: [PATCH/RFC 02/11] strbuf: add non-variadic function strbuf_vaddf()
From: Paolo Bonzini @ 2009-11-26 11:13 UTC (permalink / raw)
To: git; +Cc: msysgit
In-Reply-To: <40aa078e0911260238rd0c90cag126709d1de5f50de@mail.gmail.com>
On 11/26/2009 11:38 AM, Erik Faye-Lund wrote:
> In practice it seems that something like the following works
> portably-enough for many applications, dunno if it's something we'll
> be happy with:
> #ifndef va_copy
> #define va_copy(a,b) ((a) = (b))
> #endif
Yes, this is correct.
Paolo
^ permalink raw reply
* Re: [RFC/PATCHv8 08/10] fast-import: Proper notes tree manipulation using the notes API
From: Johan Herland @ 2009-11-26 11:10 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, gitster
In-Reply-To: <20091126024655.GR11919@spearce.org>
On Thursday 26 November 2009, Shawn O. Pearce wrote:
> Johan Herland <johan@herland.net> wrote:
> > This patch teaches 'git fast-import' to use the notes API to
> > organize
>
> ...
>
> > This patch is substantially different from the previous iteration.
> > Unloading (and reloading) the notes tree along with its
> > corresponding branch was relatively straightforward to fix, but
> > avoiding the destroying and re-adding of all the notes in every
> > commit was much harder. After 3-4 attempts at a simpler (but
> > fundamentally broken) approach, I finally landed on this. I'm not
> > satisfied with the amount of code introduced by this patch, and
> > would be happy if someone found a better/shorter/more elegant way
> > to solve this problem.
>
> Yea, I agree, I'm not happy with the amount of complex code added
> to implement this. But I can't say there's a better way to do it
> and still reuse the notes code. Maybe its just worth breaking away
> from the notes code altogether? fast-import also implements its
> own pack formatting functions because reusing them from pack-objects
> was just too ugly.
Ok, I will attempt to redo the patch without reusing the notes code. I
have couple of ideas on how to get it done, but probably won't have the
time to implement them until next week...
> Aside from a few minor nits below though, I could ACK this, it at
> least avoids the nasty corners that can arise when there are a lot
> of branches and tries to minimize the cost when there are many notes.
>
> > diff --git a/fast-import.c b/fast-import.c
> > +
> > +static void add_to_replace_list(
> > + struct tree_entry_replace **replace_list,
> > + const char *old_path, const char *new_path)
> > +{
> > + struct tree_entry_replace *r = (struct tree_entry_replace *)
> > + xmalloc(sizeof(struct tree_entry_replace));
> > + r->next = (*replace_list)->next;
> > + r->old_path = xstrdup(old_path);
> > + r->new_path = xstrdup(new_path);
> > + (*replace_list)->next = r;
> > + *replace_list = r;
>
> Really? I don't get why you are replacing the head's next with r
> only to then replace head itself with r.
>
> > @@ -2265,6 +2540,18 @@ static void parse_new_commit(void)
> > break;
> > }
> >
> > + if (notes) {
> > + /* reconcile diffs between b->branch_tree and the notes tree */
> > + struct reconcile_notes_tree_helper_data d;
> > + struct tree_entry_replace *replace_list =
> > + xcalloc(1, sizeof(struct tree_entry_replace));
>
> Oh, I see. The issue I had with understanding add_to_replace_list()
> is due to this spot allocating a blank header node. Normally we do
> this with a pointer to a pointer and initialize NULL:
>
> struct tree_entry_replace *list = NULL;
> struct tree_entry_replace **replace_list = &list;
>
> Can we avoid this blank header node? I think it comlicates the code,
> e.g. in process_replace_list() you have to skip over the blank node
> by testing for both paths being NULL.
The main problem is that I need to grow a linked list at the far end,
while keeping a reference to the first element, so that
process_replace_list() traverse the list in the correct order (FIFO).
However, I agree that my approach to doing so may have been somewhat
ham-fisted... Will redo (unless the alternative approach above renders
this code obsolete).
BTW, while we're on the topic, this whole code is only present because I
assume it's not possible to edit the fast-import tree structure _while_
traversing it. Is this assumption correct, or are there ways to get
around maintaining a separate edit list that is applied to the tree
structure afterwards?
Thanks for the review! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [PATCH/RFC 01/11] mingw: add network-wrappers for daemon
From: Martin Storsjö @ 2009-11-26 11:03 UTC (permalink / raw)
To: kusmabite; +Cc: msysgit, git, dotzenlabs
In-Reply-To: <40aa078e0911260246j47fa36d5t421de7c1d07d5cca@mail.gmail.com>
On Thu, 26 Nov 2009, Erik Faye-Lund wrote:
> Yeah, I saw your patches, and realized that I needed to rebase my work
> at some point, but none of the repos I usually pull from seems to
> contain the patches yet. Rebasing will be a requirement before this
> can be applied for sure.
Ok, great! I tried applying it on the latest master, and it wasn't too
much of work.
> > Also, the getaddrinfo-compatibility wrappers perhaps may need some minor
> > updates to handle the use cases needed for setting up listening sockets.
>
> I expect you're referring to IPv6 support in the wrappers this patch
> adds? Unfortunately IPv6 isn't something I'm very familiar with, but
> I'll give it a go unless someone else provides some patches...
No, sorry for being unclear.
When IPv6 is enabled, name lookups go through getaddrinfo instead of
gethostbyname. Since getaddrinfo isn't available on Win2k (and switching
between getaddrinfo/gethostbyname happens at compile time when IPv6 is
enabled), we have to provide a small getaddrinfo stub, implemented in
terms of gethostbyname. This currently implements only parts of the
getaddrinfo interface - enough for the way getaddrinfo was used this far.
git-daemon uses getaddrinfo in a slightly different way (for setting up
listening sockets), and thus uses parameters that our current getaddrinfo
stub doesn't support. The patch I sent to this thread a moment ago adds
support for the way git-daemon uses getaddrinfo.
I tested this patch series on top of the latest master, with IPv6 support,
and found a slight problem caused by the IPv6 support. If IPv6 isn't
enabled, git-daemon always listens on one single socket, otherwise it may
listen on two separate sockets, one for v4 and one for v6.
This causes problems with the mingw poll() replacement, which has a
special case for polling one single fd - otherwise it tries to use some
emulation that currently only works for pipes. I didn't try to make any
proper fix for this though. I tested git-daemon by hacking it to listen on
only one of the sockets, and that worked well for both v4 and v6.
So, in addition to the getaddrinfo patch I sent, the mingw poll()
replacement needs some updates to handle polling multiple sockets. Except
from that, things seem to work, at a quick glance.
// Martin
^ permalink raw reply
* Re: [PATCH/RFC 01/11] mingw: add network-wrappers for daemon
From: Erik Faye-Lund @ 2009-11-26 10:46 UTC (permalink / raw)
To: Martin Storsjö; +Cc: msysgit, git, dotzenlabs
In-Reply-To: <alpine.DEB.2.00.0911261015140.14228@cone.home.martin.st>
On Thu, Nov 26, 2009 at 9:24 AM, Martin Storsjö <martin@martin.st> wrote:
> Hi,
>
> First of all, great that you're working on adding daemon support for
> windows!
Thanks. I meant to send this out a couple of weeks ago, but I wasn't
able to find the time until now.
Also, I wouldn't have come this far without going tired of it without
Mike's patches, so some credit should go to him for doing good initial
work!
> On Thu, 26 Nov 2009, Erik Faye-Lund wrote:
>
>> +static void wsa_init(void)
>> {
>> + static int initialized = 0;
>> WSADATA wsa;
>>
>> + if (initialized)
>> + return;
>> +
>> if (WSAStartup(MAKEWORD(2,2), &wsa))
>> die("unable to initialize winsock subsystem, error %d",
>> WSAGetLastError());
>> atexit((void(*)(void)) WSACleanup);
>> + initialized = 1;
>> +}
>
> Something similar to this was merged into master recently as part of my
> mingw/ipv6 patches, so by rebasing your patch on top of that, this patch
> will probably get a bit smaller.
Yeah, I saw your patches, and realized that I needed to rebase my work
at some point, but none of the repos I usually pull from seems to
contain the patches yet. Rebasing will be a requirement before this
can be applied for sure.
>
> Also, the getaddrinfo-compatibility wrappers perhaps may need some minor
> updates to handle the use cases needed for setting up listening sockets.
I expect you're referring to IPv6 support in the wrappers this patch
adds? Unfortunately IPv6 isn't something I'm very familiar with, but
I'll give it a go unless someone else provides some patches...
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* [PATCH] Improve the mingw getaddrinfo stub to handle more use cases
From: Martin Storsjö @ 2009-11-26 10:43 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: msysgit, git, dotzenlabs, Erik Faye-Lund
In-Reply-To: <alpine.DEB.2.00.0911261015140.14228@cone.home.martin.st>
Allow the node parameter to be null, which is used for getting
the default bind address.
Also allow the hints parameter to be null, to improve standard
conformance of the stub implementation a little.
Signed-off-by: Martin Storsjo <martin@martin.st>
---
This patch adds support for the getaddrinfo parameters used by git-daemon,
as mentioned earlier.
compat/mingw.c | 20 +++++++++++++-------
1 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/compat/mingw.c b/compat/mingw.c
index 0653560..17d1314 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -913,19 +913,22 @@ static int WSAAPI getaddrinfo_stub(const char *node, const char *service,
const struct addrinfo *hints,
struct addrinfo **res)
{
- struct hostent *h = gethostbyname(node);
+ struct hostent *h = NULL;
struct addrinfo *ai;
struct sockaddr_in *sin;
- if (!h)
- return WSAGetLastError();
+ if (node) {
+ h = gethostbyname(node);
+ if (!h)
+ return WSAGetLastError();
+ }
ai = xmalloc(sizeof(struct addrinfo));
*res = ai;
ai->ai_flags = 0;
ai->ai_family = AF_INET;
- ai->ai_socktype = hints->ai_socktype;
- switch (hints->ai_socktype) {
+ ai->ai_socktype = hints ? hints->ai_socktype : 0;
+ switch (ai->ai_socktype) {
case SOCK_STREAM:
ai->ai_protocol = IPPROTO_TCP;
break;
@@ -937,14 +940,17 @@ static int WSAAPI getaddrinfo_stub(const char *node, const char *service,
break;
}
ai->ai_addrlen = sizeof(struct sockaddr_in);
- ai->ai_canonname = strdup(h->h_name);
+ ai->ai_canonname = h ? strdup(h->h_name) : NULL;
sin = xmalloc(ai->ai_addrlen);
memset(sin, 0, ai->ai_addrlen);
sin->sin_family = AF_INET;
if (service)
sin->sin_port = htons(atoi(service));
- sin->sin_addr = *(struct in_addr *)h->h_addr;
+ if (h)
+ sin->sin_addr = *(struct in_addr *)h->h_addr;
+ else
+ sin->sin_addr.s_addr = INADDR_ANY;
ai->ai_addr = (struct sockaddr *)sin;
ai->ai_next = 0;
return 0;
--
1.6.4.4
^ permalink raw reply related
* Re: [PATCH/RFC 02/11] strbuf: add non-variadic function strbuf_vaddf()
From: Erik Faye-Lund @ 2009-11-26 10:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: msysgit, git, dotzenlabs, Alex Riesen
In-Reply-To: <7vskc2ksnn.fsf@alter.siamese.dyndns.org>
On Thu, Nov 26, 2009 at 1:59 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Erik Faye-Lund <kusmabite@googlemail.com> writes:
>
>> +void strbuf_vaddf(struct strbuf *sb, const char *fmt, va_list ap)
>> {
>> int len;
>>
>> if (!strbuf_avail(sb))
>> strbuf_grow(sb, 64);
>> len = vsnprintf(sb->buf + sb->len, sb->alloc - sb->len, fmt, ap);
>> if (len < 0)
>> die("your vsnprintf is broken");
>> if (len > strbuf_avail(sb)) {
>> strbuf_grow(sb, len);
>> len = vsnprintf(sb->buf + sb->len, sb->alloc - sb->len, fmt, ap);
>> if (len > strbuf_avail(sb)) {
>> die("this should not happen, your snprintf is broken");
>> }
>
> Hmm, I would have expected to see va_copy() somewhere in the patch text.
> Is it safe to reuse ap like this in two separate invocations of
> vsnprintf()?
>
I think your expectation is well justified, this seems to be a
portability-bug waiting to happen. Sorry for missing this prior to
sending out - on Windows this is known to work, and this function is
currently only used from the Windows implementation of syslog.
How kosher is it to use va_copy in the git-core, considering that it's
C99? A quick grep reveals only one occurrence of va_copy in the
source, and that's in compat/winansi.c. Searching the history of next
reveals that Alex Riesen (CC'd) already removed one occurrence
(4bf5383), so I'm starting to get slightly scared it might not be OK.
In practice it seems that something like the following works
portably-enough for many applications, dunno if it's something we'll
be happy with:
#ifndef va_copy
#define va_copy(a,b) ((a) = (b))
#endif
--
Erik "kusma" Faye-Lund
^ 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