191–200 of 342 posts
Earlier quoted context omitted.
The obsession of git users with rewriting history has always puzzled me. I like that the feature exists, because it is very occasionally useful, but it's one of those things you should almost never use. The whole point of history is to have a record of what happened. If you're going around and changing it, then you no longer have a record of what happened, but a record of what you kind of wish had actually happened.…
The point of rebasing for clarity, IMHO, is to take what might be a large, unorganized commit or commits (i.e. the result of a few hours good hacking) and turning it into a coherent story of how that feature is implemented. This means splitting it into commits (which change one thing), giving them good commit messages (describing the one thing and its effects), and putting them in the right order. Rather than hiding…
replaying changes is much more comfortable to me, especially when I have them in shot term memory, surely easier than merging other people stuff within your files
my average feature is around 7-10 commits, all replayed on latest commit on the branch. it forces me to catch up with other people work on shared areas and gives me quite some more confidence that merge isn't messing up with problematic files.
Earlier quoted context omitted.
The point of rebasing for clarity, IMHO, is to take what might be a large, unorganized commit or commits (i.e. the result of a few hours good hacking) and turning it into a coherent story of how that feature is implemented. This means splitting it into commits (which change one thing), giving them good commit messages (describing the one thing and its effects), and putting them in the right order. Rather than hiding…
I agree with you, but only for local commits that haven't been pushed to a shared repo. Rewriting local history seems no different than rewriting code in your editor. Rewriting shared history is (almost) always bad.
Agreed. The one counterexample that I have is Github pull requests. Those are actually branches in your fork, and you do want to rewrite those when you get feedback on a pull request. That makes it easier for the owner of the repo to do the merge later.
Earlier quoted context omitted.
Edit: There's a well-written solution for that here: https://news.ycombinator.com/item?id=9745367
Parent was deleted.
Instead of taking the branch and rebasing it, make a branch called .1 on top of , then rebase that, leaving in place.
That way all your references remain intact and you can compare CI results.
Increment the number as needed.
Earlier quoted context omitted.
Can't reply to mikeash below, but I also have a comment. I've burnt myself a few times where I committed something and pushed to my remote repo, only to realise that I shouldn't have. What I've taken from my errors is that I no longer push single commits until I'm at least done with what I'm doing (I use GitFlow btw). It's easier for such things to happen in languages where you don't need to build your project (looki…
Even in a language like JavaScript, you're at least running your new code before you commit, surely. As for a fix which introduces a regression somewhere else, that seems like exactly the sort of history you'd want to capture in source control. "Fixed X." "The fix for X broke Y, which is now fixed." This is much more informative than a single "Fixed X." which only includes the final state. The fact that a fix for X c…
Not for any other project where maintenance releases are a norm. This includes stuff strict API compatibility projects, semantically versioned frameworks/plugins/libraries, many forms of desktop/offline apps, some android apps, most enterprise apps, etc - more or less where developers don't have the liberty to thrust the latest master on their users.
I'm not against CD, and not a big fan of Git Flow either. But different things have their own uses. I'm really liking GitHub Flow and GitLab Flow though!
Earlier quoted context omitted.
If you are using the Integration-Manager workflow (which GitLab doesn't support as well as Bitbucket or GitHub), all the members of a team have read access to all the repositories and forks in the team namespace. That means the owner of a developer branch fork can always read the repo of another contributor and pull the changes.
Please let me know what you think we should improve to support that workflow better. Anyway, I think my examples are still valid, it is harder to mention issues and you can't push (write) commits on forks since your have read permissions.
The main assumption in the Integration-Manager workflow is that code from repositories of other users is always pulled by the owner of the current repository as and when appropriate.
So if dev1 and dev2 are working on the same feature in 2 different forks of the main repository, dev1 has to pull commits from dev2 that are needed in his/her fork and dev2 has to do the same in his/her fork. Once the feature is complete, the merge request is created from one of the 2 forks.
Yes it is harder to mention issues, but that can be done in the message of the merge commit. Since forks are essentially equivalent to branches in this workflow, I usually don't mind referring to issues in the individual commits itself which would link to the correct issue on getting merged to the main repository.
We do this with our team's projects hosted on Bitbucket, ymmv.
Earlier quoted context omitted.
The obsession of git users with rewriting history has always puzzled me. I like that the feature exists, because it is very occasionally useful, but it's one of those things you should almost never use. The whole point of history is to have a record of what happened. If you're going around and changing it, then you no longer have a record of what happened, but a record of what you kind of wish had actually happened.…
The point of rebasing for clarity, IMHO, is to take what might be a large, unorganized commit or commits (i.e. the result of a few hours good hacking) and turning it into a coherent story of how that feature is implemented. This means splitting it into commits (which change one thing), giving them good commit messages (describing the one thing and its effects), and putting them in the right order. Rather than hiding…
Isn't this the same rationalization that drives Git Flow's feature branches and merging via --no-ff ? You can see the messy real work in the feature branch, but it gets merged to the main branch as one clean commit.
I apologize for the self-promotion, but this answer on Stack Overflow (and the question) talks about this difference between Git and Mercurial, and includes links to articles that explain it better than I could:
Earlier quoted context omitted.
Even in a language like JavaScript, you're at least running your new code before you commit, surely. As for a fix which introduces a regression somewhere else, that seems like exactly the sort of history you'd want to capture in source control. "Fixed X." "The fix for X broke Y, which is now fixed." This is much more informative than a single "Fixed X." which only includes the final state. The fact that a fix for X c…
In JavaScript you have to contend with a dozen different run environments. Maybe you realized your fix actually broke the feature in IE8 because you left a comma at the end of an array. It's quite common to have your fix break something in a very specific environment.